Re: [strongSwan] Kernel panic with VTI tunnel
For reference, this is the kernel bug report, including a fix, for kernel crashes when using a VTI tunnel: https://bugzilla.kernel.org/show_bug.cgi?id=95211 Not sure if it is VTI specific though. Regards, Mike On 22 March 2015 at 14:31, Mike Noordermeer m...@normi.net wrote: FYI, the issue is still present in the latest 4.0 kernel, so VTI tunnels seem to be fairly unusable at the moment (at least for me they are). I filed a kernel bug at https://bugzilla.kernel.org/show_bug.cgi?id=95211 I'll probably switch to a GRE tunnel for the time being. Regards, Mike On 16 March 2015 at 10:37, André Valentin avalen...@marcant.net wrote: Hi Mike, that's right. I had no time to take a deeper look. Perhaps you have;-) Kind regards, André Am 16.03.2015 um 10:30 schrieb Mike Noordermeer: Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype
Re: [strongSwan] Kernel panic with VTI tunnel
FYI, the issue is still present in the latest 4.0 kernel, so VTI tunnels seem to be fairly unusable at the moment (at least for me they are). I filed a kernel bug at https://bugzilla.kernel.org/show_bug.cgi?id=95211 I'll probably switch to a GRE tunnel for the time being. Regards, Mike On 16 March 2015 at 10:37, André Valentin avalen...@marcant.net wrote: Hi Mike, that's right. I had no time to take a deeper look. Perhaps you have;-) Kind regards, André Am 16.03.2015 um 10:30 schrieb Mike Noordermeer: Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype
Re: [strongSwan] Kernel panic with VTI tunnel
Hi Mike, that's right. I had no time to take a deeper look. Perhaps you have;-) Kind regards, André Am 16.03.2015 um 10:30 schrieb Mike Noordermeer: Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_statistic xt_CT xt_realm xt_LOG iptable_raw xt_connlimit xt_addrtype xt_comment xt_nat xt_recent ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc
Re: [strongSwan] Kernel panic with VTI tunnel
Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444]
Re: [strongSwan] Kernel panic with VTI tunnel
Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes))
Re: [strongSwan] Kernel panic with VTI tunnel
Hi Mike, Should be completely unrelated, but I encountered kernel panic every 2 days, and I switched to openvpn. picture: http://img.vim-cn.com/bf/6563b61ec8c08960e74fe5c12390e21c5174b6.png kernel is 3.19.1 on KVM, strongswan 5.2.2. Mike Noordermeer m...@normi.net writes: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_statistic xt_CT xt_realm xt_LOG iptable_raw xt_connlimit xt_addrtype xt_comment xt_nat xt_recent ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp xt_set ip_set nf_nat_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane nf_conntrack_proto_udplite
Re: [strongSwan] Kernel panic with VTI tunnel
Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_statistic xt_CT xt_realm xt_LOG iptable_raw xt_connlimit xt_addrtype xt_comment xt_nat xt_recent ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp xt_set ip_set nf_nat_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc
