diff mbox

3.12.33 - BUG xfrm_selector_match+0x25/0x2f6

Message ID alpine.LFD.2.11.1412072019410.1885@ja.home.ssi.bg
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Julian Anastasov Dec. 7, 2014, 6:27 p.m. UTC 
Hello,

On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:

> thank you for the fast responses! I would like to test any patch for 3.12.

	I'm attaching a patch that avoids rerouting in
IPVS for LOCAL_IN. Please test it in your setup. My tests
were with NAT on today's net tree. I checked that it
compiles for 3.12.33. You can use the default snat_reroute=1.

Regards

--
Julian Anastasov <ja@ssi.bg>
From 4fc493f8f1ed967b1e3dd6d330a25bad762516d7 Mon Sep 17 00:00:00 2001
From: Julian Anastasov <ja@ssi.bg>

Date: Sun, 7 Dec 2014 18:13:24 +0200
Subject: [PATCH net] ipvs: rerouting to local clients is not needed anymore

commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
ip_send_reply()." from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.

Signed-off-by: Julian Anastasov <ja@ssi.bg>

---
 net/netfilter/ipvs/ip_vs_core.c | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

-- 
1.9.3

Comments

Smart Weblications GmbH - Florian Wiessner Dec. 8, 2014, 11:19 a.m. UTC | #1 
Hi Julian,

Am 07.12.2014 19:27, schrieb Julian Anastasov:>
> 	Hello,
>
> On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> thank you for the fast responses! I would like to test any patch for 3.12.
>
> 	I'm attaching a patch that avoids rerouting in
> IPVS for LOCAL_IN. Please test it in your setup. My tests
> were with NAT on today's net tree. I checked that it
> compiles for 3.12.33. You can use the default snat_reroute=1.
>

I'm sorry to tell you that your patch does not fix the problem. The BUG happens
as soon as the client sends PASV, the ftp server does not return "Entering
Passive Mode":

[   91.862502] BUG: unable to handle kernel NULL pointer dereference at
0000000000000014
[   91.862735] IP: [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[   91.862889] PGD 0
[   91.863026] Oops: 0000 [#1] SMP
[   91.863235] Modules linked in: netconsole xt_nat xt_multiport ip_vs_rr veth
iptable_mangle xt_mark nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter
ip_tables cpufreq_ondemand cpufreq_powersave cpufreq_conservative
cpufreq_userspace ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse
nf_conntrack_ftp 8021q openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs
dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm
coretemp ip_vs_ftp ip_vs nf_nat nf_conntrack i2c_i801 psmouse serio_raw lpc_ich
mfd_core evdev btrfs lzo_decompress lzo_compress
[   91.866846] CPU: 1 PID: 18895 Comm: vsftpd Not tainted 3.12.33 #5
[   91.866927] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
09/28/2011
[   91.867023] task: ffff8807b9360540 ti: ffff8807afe90000 task.ti: ffff8807afe90000
[   91.867116] RIP: 0010:[<ffffffffa013a470>]  [<ffffffffa013a470>]
nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[   91.867268] RSP: 0018:ffff88083fc43988  EFLAGS: 00010206
[   91.867346] RAX: 000000000000000c RBX: ffff88079aeb006c RCX: 0000000000000003
[   91.867428] RDX: 000000000000002a RSI: 0000000000000003 RDI: ffff88079aeb006c
[   91.867509] RBP: 00000000ce63f6dd R08: ffff8807b2eed780 R09: ffff88083fc43998
[   91.867598] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[   91.867679] R13: 0000000000000000 R14: 0000000000000003 R15: ffff880815d948bc
[   91.867761] FS:  00007f1a8aad5700(0000) GS:ffff88083fc40000(0000)
knlGS:0000000000000000
[   91.867855] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   91.867926] CR2: 0000000000000014 CR3: 00000007a386a000 CR4: 00000000000407e0
[   91.868008] Stack:
[   91.868073]  ffff88081690d220 0000000000000012 0000000000000014 ffff88079aeb0068
[   91.868383]  ffff880815d94801 ffffffffa014f681 0000000000000000 ffffffff00000045
[   91.868694]  ffff880800000048 0000001b00000003 ffff88083fc43a60 ffff88081690d220
[   91.869003] Call Trace:
[   91.869077]  <IRQ>
[   91.869136]  [<ffffffffa014f681>] ? __nf_nat_mangle_tcp_packet+0x109/0x120
[nf_nat]
[   91.869356]  [<ffffffffa017749e>] ? ip_vs_ftp_out.part.8+0x2b2/0x338 [ip_vs_ftp]
[   91.869460]  [<ffffffffa015f884>] ? ip_vs_app_pkt_out+0x105/0x18b [ip_vs]
[   91.869539]  [<ffffffffa0163028>] ? tcp_snat_handler+0x6b/0x320 [ip_vs]
[   91.869622]  [<ffffffffa0155d3d>] ? ip_vs_conn_out_get_proto+0x1c/0x25 [ip_vs]
[   91.869736]  [<ffffffffa015893c>] ? ip_vs_out+0x2a5/0x5f6 [ip_vs]
[   91.869826]  [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[   91.869906]  [<ffffffff81508e1f>] ? nf_iterate+0x42/0x80
[   91.869996]  [<ffffffff81508ec6>] ? nf_hook_slow+0x69/0xff
[   91.870073]  [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[   91.870153]  [<ffffffff8150f8ae>] ? ip_forward+0x22d/0x2cf
[   91.870230]  [<ffffffff814e57ce>] ? __netif_receive_skb_core+0x5f0/0x66c
[   91.870311]  [<ffffffff814e59df>] ? process_backlog+0x13e/0x13e
[   91.870389]  [<ffffffffa0455e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
[   91.870482]  [<ffffffff814e5a2b>] ? netif_receive_skb+0x4c/0x7d
[   91.870561]  [<ffffffffa0455d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
[   91.870652]  [<ffffffffa0455fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
[   91.870733]  [<ffffffff814e567d>] ? __netif_receive_skb_core+0x49f/0x66c
[   91.870817]  [<ffffffff8104daa3>] ? call_timer_fn+0x4b/0xf6
[   91.870893]  [<ffffffff814e592b>] ? process_backlog+0x8a/0x13e
[   91.870972]  [<ffffffff814e5c31>] ? net_rx_action+0xa2/0x1c0
[   91.871051]  [<ffffffff81047e2e>] ? __do_softirq+0xf6/0x24f
[   91.871132]  [<ffffffff815ad7dc>] ? call_softirq+0x1c/0x30
[   91.871203]  <EOI>
[   91.871260]  [<ffffffff8100464d>] ? do_softirq+0x2c/0x5f
[   91.871470]  [<ffffffff81047ca1>] ? local_bh_enable+0x67/0x85
[   91.871545]  [<ffffffff81511689>] ? ip_finish_output+0x2c9/0x322
[   91.871628]  [<ffffffff8151240a>] ? ip_queue_xmit+0x2b7/0x2f0
[   91.871714]  [<ffffffff81524772>] ? tcp_transmit_skb+0x6ef/0x755
[   91.871792]  [<ffffffff815250e8>] ? tcp_write_xmit+0x886/0x9cb
[   91.871872]  [<ffffffff8152527a>] ? __tcp_push_pending_frames+0x24/0x7e
[   91.871951]  [<ffffffff8151a33c>] ? tcp_sendmsg+0xa4c/0xbfc
[   91.872036]  [<ffffffff814d3477>] ? sock_aio_write+0xe3/0xfd
[   91.872129]  [<ffffffff81122f4d>] ? do_sync_write+0x59/0x79
[   91.872215]  [<ffffffff811239e3>] ? vfs_write+0xc4/0x182
[   91.872298]  [<ffffffff81123daf>] ? SyS_write+0x45/0x7c
[   91.872382]  [<ffffffff815ac35b>] ? tracesys+0xdd/0xe2
[   91.872461] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 12 47 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
[   91.876166] RIP  [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[   91.876327]  RSP <ffff88083fc43988>
[   91.876400] CR2: 0000000000000014
[   91.876497] ---[ end trace 2c6d9f405db2170c ]---
[   91.876578] Kernel panic - not syncing: Fatal exception in interrupt
[   91.876666] Rebooting in 10 seconds..
[  101.935360] ACPI MEMORY or I/O RESET_REG.



node01:/ocfs2/usr/src/linux-3.12.33/scripts# ./decodecode
</tmp/node01-kernel-ipvs.log
[ 91.872461] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 12 47 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
All code
========
   0:   68 14 4d 01 c5          pushq  $0xffffffffc5014d14
   5:   45 85 e4                test   %r12d,%r12d
   8:   74 46                   je     0x50
   a:   f0 80 4f 78 40          lock orb $0x40,0x78(%rdi)
   f:   48 8d 5f 04             lea    0x4(%rdi),%rbx
  13:   48 89 df                mov    %rbx,%rdi
  16:   e8 00 12 47 e1          callq  0xffffffffe147121b
  1b:   31 c0                   xor    %eax,%eax
  1d:   41 83 fe 02             cmp    $0x2,%r14d
  21:   0f 97 c0                seta   %al
  24:   48 6b c0 0c             imul   $0xc,%rax,%rax
  28:   4c 01 e8                add    %r13,%rax
  2b:*  8b 70 08                mov    0x8(%rax),%esi           <-- trapping
instruction
  2e:   39 70 04                cmp    %esi,0x4(%rax)
  31:   74 08                   je     0x3b
  33:   89 ea                   mov    %ebp,%edx
  35:   0f ca                   bswap  %edx
  37:   39 10                   cmp    %edx,(%rax)
  39:   79 0d                   jns    0x48
  3b:   89 70 04                mov    %esi,0x4(%rax)
  3e:   44                      rex.R
  3f:   01                      .byte 0x1

Code starting with the faulting instruction
===========================================
   0:   8b 70 08                mov    0x8(%rax),%esi
   3:   39 70 04                cmp    %esi,0x4(%rax)
   6:   74 08                   je     0x10
   8:   89 ea                   mov    %ebp,%edx
   a:   0f ca                   bswap  %edx
   c:   39 10                   cmp    %edx,(%rax)
   e:   79 0d                   jns    0x1d
  10:   89 70 04                mov    %esi,0x4(%rax)
  13:   44                      rex.R
  14:   01                      .byte 0x1
Julian Anastasov Dec. 8, 2014, 8:40 p.m. UTC | #2 
Hello,

On Mon, 8 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:

> Am 07.12.2014 19:27, schrieb Julian Anastasov:>
> >
> > 	I'm attaching a patch that avoids rerouting in
> > IPVS for LOCAL_IN. Please test it in your setup. My tests
> > were with NAT on today's net tree. I checked that it
> > compiles for 3.12.33. You can use the default snat_reroute=1.
> >
> 
> I'm sorry to tell you that your patch does not fix the problem. The BUG happens
> as soon as the client sends PASV, the ftp server does not return "Entering
> Passive Mode":

	Patch is to avoid the xfrm_selector_match crash,
may be caused when using local client (mail?).
For nf_ct_seqadj_set you have to use commit b25adce16064
("ipvs: correct usage/allocation of seqadj ext in ipvs").
I'll send it to you privately...

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Smart Weblications GmbH - Florian Wiessner Dec. 9, 2014, 10:23 a.m. UTC | #3 
Hi Julian,

Am 08.12.2014 21:40, schrieb Julian Anastasov:
> 
> 	Hello,
> 
> On Mon, 8 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> 
>> Am 07.12.2014 19:27, schrieb Julian Anastasov:>
>>>
>>> 	I'm attaching a patch that avoids rerouting in
>>> IPVS for LOCAL_IN. Please test it in your setup. My tests
>>> were with NAT on today's net tree. I checked that it
>>> compiles for 3.12.33. You can use the default snat_reroute=1.
>>>
>>
>> I'm sorry to tell you that your patch does not fix the problem. The BUG happens
>> as soon as the client sends PASV, the ftp server does not return "Entering
>> Passive Mode":
> 
> 	Patch is to avoid the xfrm_selector_match crash,
> may be caused when using local client (mail?).
> For nf_ct_seqadj_set you have to use commit b25adce16064
> ("ipvs: correct usage/allocation of seqadj ext in ipvs").
> I'll send it to you privately...
> 

I rebuild everything with the two provided patches and still get:

[  512.475449] BUG: unable to handle kernel NULL pointer dereference at
0000000000000014
[  512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[  512.481442] PGD 0
[  512.481572] Oops: 0000 [#1] SMP
[  512.481750] Modules linked in: ip_vs_rr netconsole xt_nat xt_multiport veth
iptable_mangle xt_mark nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter
ip_tables cpufreq_ondemand cpufreq_powersave cpufreq_conservative
cpufreq_userspace ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse
nf_conntrack_ftp 8021q openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs
dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm
coretemp ip_vs_ftp ip_vs nf_nat nf_conntrack psmouse serio_raw i2c_i801 lpc_ich
mfd_core evdev btrfs lzo_decompress lzo_compress
[  512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
[  512.485405] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
09/28/2011
[  512.485497] task: ffff880703f1c500 ti: ffff8805cab2e000 task.ti: ffff8805cab2e000
[  512.485594] RIP: 0010:[<ffffffffa013d470>]  [<ffffffffa013d470>]
nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[  512.485751] RSP: 0018:ffff88083fd03988  EFLAGS: 00010206
[  512.485829] RAX: 000000000000000c RBX: ffff8805cb314b1c RCX: 0000000000000003
[  512.485916] RDX: 0000000000000026 RSI: 0000000000000003 RDI: ffff8805cb314b1c
[  512.486007] RBP: 00000000030a6079 R08: ffff88079d058c80 R09: ffff88083fd03998
[  512.486084] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[  512.486162] R13: 0000000000000000 R14: 0000000000000003 R15: ffff8808170150bc
[  512.486240] FS:  00007f0497645700(0000) GS:ffff88083fd00000(0000)
knlGS:0000000000000000
[  512.486351] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  512.486431] CR2: 0000000000000014 CR3: 00000007457f4000 CR4: 00000000000407e0
[  512.486512] Stack:
[  512.486583]  ffff88077b389460 0000000000000012 0000000000000014 ffff8805cb314b18
[  512.486886]  ffff880817015001 ffffffffa0152681 0000000000000000 ffffffff00000045
[  512.487195]  ffff880800000048 0000001b00000003 ffff88083fd03a60 ffff88077b389460
[  512.487501] Call Trace:
[  512.487574]  <IRQ>
[  512.487634]  [<ffffffffa0152681>] ? __nf_nat_mangle_tcp_packet+0x109/0x120
[nf_nat]
[  512.487859]  [<ffffffffa017a49e>] ? ip_vs_ftp_out.part.8+0x2b2/0x338 [ip_vs_ftp]
[  512.487957]  [<ffffffffa0162884>] ? ip_vs_app_pkt_out+0x105/0x18b [ip_vs]
[  512.488038]  [<ffffffffa0166028>] ? tcp_snat_handler+0x6b/0x320 [ip_vs]
[  512.488123]  [<ffffffffa0158d3d>] ? ip_vs_conn_out_get_proto+0x1c/0x25 [ip_vs]
[  512.488222]  [<ffffffffa015b93c>] ? ip_vs_out+0x2a5/0x5f6 [ip_vs]
[  512.488325]  [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[  512.488405]  [<ffffffff81508e1f>] ? nf_iterate+0x42/0x80
[  512.488486]  [<ffffffff81508ec6>] ? nf_hook_slow+0x69/0xff
[  512.488565]  [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[  512.488645]  [<ffffffff8150f8ae>] ? ip_forward+0x22d/0x2cf
[  512.488729]  [<ffffffff814e57ce>] ? __netif_receive_skb_core+0x5f0/0x66c
[  512.488810]  [<ffffffff814e59df>] ? process_backlog+0x13e/0x13e
[  512.488893]  [<ffffffffa0458e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
[  512.488987]  [<ffffffff814e5a2b>] ? netif_receive_skb+0x4c/0x7d
[  512.489068]  [<ffffffffa0458d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
[  512.489166]  [<ffffffffa0458fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
[  512.489247]  [<ffffffff814e567d>] ? __netif_receive_skb_core+0x49f/0x66c
[  512.489338]  [<ffffffff814e592b>] ? process_backlog+0x8a/0x13e
[  512.489415]  [<ffffffff814e5c31>] ? net_rx_action+0xa2/0x1c0
[  512.489493]  [<ffffffff81047e2e>] ? __do_softirq+0xf6/0x24f
[  512.489578]  [<ffffffff815ad7dc>] ? call_softirq+0x1c/0x30
[  512.489655]  <EOI>
[  512.489721]  [<ffffffff8100464d>] ? do_softirq+0x2c/0x5f
[  512.489920]  [<ffffffff81047ca1>] ? local_bh_enable+0x67/0x85
[  512.489996]  [<ffffffff81511689>] ? ip_finish_output+0x2c9/0x322
[  512.490076]  [<ffffffff8151240a>] ? ip_queue_xmit+0x2b7/0x2f0
[  512.490156]  [<ffffffff81524772>] ? tcp_transmit_skb+0x6ef/0x755
[  512.490235]  [<ffffffff815250e8>] ? tcp_write_xmit+0x886/0x9cb
[  512.490311]  [<ffffffff8152527a>] ? __tcp_push_pending_frames+0x24/0x7e
[  512.490392]  [<ffffffff8151a33c>] ? tcp_sendmsg+0xa4c/0xbfc
[  512.490466]  [<ffffffff814d3477>] ? sock_aio_write+0xe3/0xfd
[  512.490545]  [<ffffffff81122f4d>] ? do_sync_write+0x59/0x79
[  512.490623]  [<ffffffff811239e3>] ? vfs_write+0xc4/0x182
[  512.490703]  [<ffffffff81123daf>] ? SyS_write+0x45/0x7c
[  512.490781]  [<ffffffff815ac35b>] ? tracesys+0xdd/0xe2
[  512.490859] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 e2 46 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
[  512.494558] RIP  [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[  512.494714]  RSP <ffff88083fd03988>
[  512.494785] CR2: 0000000000000014
[  512.494871] ---[ end trace 8a6e753cba1ccec2 ]---
Julian Anastasov Dec. 10, 2014, 9:41 p.m. UTC | #4 
Hello,

On Tue, 9 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:

> I rebuild everything with the two provided patches and still get:
> 
> [  512.475449] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000014
> [  512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]

	Same place, hm...

> [  512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5

	Above "#5" is same as previous oops. It means kernel
is not updated. Or you updated only the IPVS modules after
applying the both patches?

	You can also try without FTP tests to see if there
are oopses in xfrm, so that we can close this topic and then
to continue for the FTP problem on IPVS lists without
bothering non-IPVS people.

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Smart Weblications GmbH - Florian Wiessner Dec. 11, 2014, 2:04 p.m. UTC | #5 
Hi,

Am 10.12.2014 22:41, schrieb Julian Anastasov:>
> 	Hello,
>
> On Tue, 9 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> I rebuild everything with the two provided patches and still get:
>>
>> [  512.475449] BUG: unable to handle kernel NULL pointer dereference at
>> 0000000000000014
>> [  512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
>
> 	Same place, hm...
>
>> [  512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
>
> 	Above "#5" is same as previous oops. It means kernel
> is not updated. Or you updated only the IPVS modules after
> applying the both patches?

I did it with make-kpkg --initrd linux_image which only rebuilt the modules,
correct. I can retry with make clean before building the package

>
> 	You can also try without FTP tests to see if there
> are oopses in xfrm, so that we can close this topic and then
> to continue for the FTP problem on IPVS lists without
> bothering non-IPVS people.
>

yeah, it seems that the xfrm issue is away.
Julian Anastasov Dec. 13, 2014, 8:19 p.m. UTC | #6 
Hello,

On Thu, 11 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:

> >> [  512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
> >
> > 	Above "#5" is same as previous oops. It means kernel
> > is not updated. Or you updated only the IPVS modules after
> > applying the both patches?
> 
> I did it with make-kpkg --initrd linux_image which only rebuilt the modules,
> correct. I can retry with make clean before building the package

	I just tested PASV and PORT with 3.12.33 including
both patches (seq adj fix + ip_route_me_harder fix) and do not
see any crashes in nf_ct_seqadj_set. If you still have problem
with FTP send me more info offlist.

> > 	You can also try without FTP tests to see if there
> > are oopses in xfrm, so that we can close this topic and then
> > to continue for the FTP problem on IPVS lists without
> > bothering non-IPVS people.
> >
> 
> yeah, it seems that the xfrm issue is away.

	Thanks for the confirmation!

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiri Slaby Jan. 6, 2015, 12:56 p.m. UTC | #7 
On 12/13/2014, 09:19 PM, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Thu, 11 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> 
>>>> [  512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
>>>
>>> 	Above "#5" is same as previous oops. It means kernel
>>> is not updated. Or you updated only the IPVS modules after
>>> applying the both patches?
>>
>> I did it with make-kpkg --initrd linux_image which only rebuilt the modules,
>> correct. I can retry with make clean before building the package
> 
> 	I just tested PASV and PORT with 3.12.33 including
> both patches (seq adj fix + ip_route_me_harder fix) and do not
> see any crashes in nf_ct_seqadj_set. If you still have problem
> with FTP send me more info offlist.
> 
>>> 	You can also try without FTP tests to see if there
>>> are oopses in xfrm, so that we can close this topic and then
>>> to continue for the FTP problem on IPVS lists without
>>> bothering non-IPVS people.
>>>
>>
>> yeah, it seems that the xfrm issue is away.
> 
> 	Thanks for the confirmation!

Great! Thanks for tracking it down.

So what should be done to fix the issue in stable 3.12? Are those
patches needed in the upstream kernel too? In that case I suppose it
will propagate to me through upstream. Otherwise, could you send "3.12
only" patches to stable@ so that I can apply them?

thanks,
Julian Anastasov Jan. 6, 2015, 8:46 p.m. UTC | #8 
Hello,

On Tue, 6 Jan 2015, Jiri Slaby wrote:

> So what should be done to fix the issue in stable 3.12? Are those
> patches needed in the upstream kernel too? In that case I suppose it
> will propagate to me through upstream. Otherwise, could you send "3.12
> only" patches to stable@ so that I can apply them?

	I asked Pablo for the old fix for IPVS-FTP:

http://www.spinics.net/lists/lvs-devel/msg03879.html

	The new fix for the xfrm crash is not applied yet:

http://www.spinics.net/lists/lvs-devel/msg03877.html

Regards

--
Julian Anastasov <ja@ssi.bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 990decb..b87ca32 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -659,16 +659,24 @@  static inline int ip_vs_gather_frags(struct sk_buff *skb, u_int32_t user)
 	return err;
 }
 
-static int ip_vs_route_me_harder(int af, struct sk_buff *skb)
+static int ip_vs_route_me_harder(int af, struct sk_buff *skb,
+				 unsigned int hooknum)
 {
+	if (!sysctl_snat_reroute(skb))
+		return 0;
+	/* Reroute replies only to remote clients (FORWARD and LOCAL_OUT) */
+	if (NF_INET_LOCAL_IN == hooknum)
+		return 0;
 #ifdef CONFIG_IP_VS_IPV6
 	if (af == AF_INET6) {
-		if (sysctl_snat_reroute(skb) && ip6_route_me_harder(skb) != 0)
+		struct dst_entry *dst = skb_dst(skb);
+
+		if (dst->dev && !(dst->dev->flags & IFF_LOOPBACK) &&
+		    ip6_route_me_harder(skb) != 0)
 			return 1;
 	} else
 #endif
-		if ((sysctl_snat_reroute(skb) ||
-		     skb_rtable(skb)->rt_flags & RTCF_LOCAL) &&
+		if (!(skb_rtable(skb)->rt_flags & RTCF_LOCAL) &&
 		    ip_route_me_harder(skb, RTN_LOCAL) != 0)
 			return 1;
 
@@ -791,7 +799,8 @@  static int handle_response_icmp(int af, struct sk_buff *skb,
 				union nf_inet_addr *snet,
 				__u8 protocol, struct ip_vs_conn *cp,
 				struct ip_vs_protocol *pp,
-				unsigned int offset, unsigned int ihl)
+				unsigned int offset, unsigned int ihl,
+				unsigned int hooknum)
 {
 	unsigned int verdict = NF_DROP;
 
@@ -821,7 +830,7 @@  static int handle_response_icmp(int af, struct sk_buff *skb,
 #endif
 		ip_vs_nat_icmp(skb, pp, cp, 1);
 
-	if (ip_vs_route_me_harder(af, skb))
+	if (ip_vs_route_me_harder(af, skb, hooknum))
 		goto out;
 
 	/* do the statistics and put it back */
@@ -916,7 +925,7 @@  static int ip_vs_out_icmp(struct sk_buff *skb, int *related,
 
 	snet.ip = iph->saddr;
 	return handle_response_icmp(AF_INET, skb, &snet, cih->protocol, cp,
-				    pp, ciph.len, ihl);
+				    pp, ciph.len, ihl, hooknum);
 }
 
 #ifdef CONFIG_IP_VS_IPV6
@@ -981,7 +990,8 @@  static int ip_vs_out_icmp_v6(struct sk_buff *skb, int *related,
 	snet.in6 = ciph.saddr.in6;
 	writable = ciph.len;
 	return handle_response_icmp(AF_INET6, skb, &snet, ciph.protocol, cp,
-				    pp, writable, sizeof(struct ipv6hdr));
+				    pp, writable, sizeof(struct ipv6hdr),
+				    hooknum);
 }
 #endif
 
@@ -1040,7 +1050,8 @@  static inline bool is_new_conn(const struct sk_buff *skb,
  */
 static unsigned int
 handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
-		struct ip_vs_conn *cp, struct ip_vs_iphdr *iph)
+		struct ip_vs_conn *cp, struct ip_vs_iphdr *iph,
+		unsigned int hooknum)
 {
 	struct ip_vs_protocol *pp = pd->pp;
 
@@ -1078,7 +1089,7 @@  handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
 	 * if it came from this machine itself.  So re-compute
 	 * the routing information.
 	 */
-	if (ip_vs_route_me_harder(af, skb))
+	if (ip_vs_route_me_harder(af, skb, hooknum))
 		goto drop;
 
 	IP_VS_DBG_PKT(10, af, pp, skb, 0, "After SNAT");
@@ -1181,7 +1192,7 @@  ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af)
 	cp = pp->conn_out_get(af, skb, &iph, 0);
 
 	if (likely(cp))
-		return handle_response(af, skb, pd, cp, &iph);
+		return handle_response(af, skb, pd, cp, &iph, hooknum);
 	if (sysctl_nat_icmp_send(net) &&
 	    (pp->protocol == IPPROTO_TCP ||
 	     pp->protocol == IPPROTO_UDP ||