| Summary: | =sys-kernel/vanilla-sources-{3.7.5-r1, 3.8.3, 3.8.6} - Oops when ping host through ipsec | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Veovis <veovis8> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | pageexec, spender |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | my current kernel config with debugging enabled | ||
|
Description
Veovis
2013-05-20 11:18:37 UTC
Created attachment 348726 [details]
my current kernel config with debugging enabled
pipacs, hardened-sources-3.8.6 = grsecurity-2.9.1-3.8.6-201304052305. I have not pushed any of the latest because of the low mem issue on x86. this is a null ptr deref in the kernel. does vanilla work better? No, it doesn't. (vanilla 3.8.6, same .config) I manage to finally make the bug reproductible. This is the situation: - 2 servers A and B with each 2 interfaces, one public with ipv6 and ipv4, the other private with ipv4 only. - an ipsec ipv6 tunnel to link the two ipv4 private network - this iptable rule on A: iptables -t nat -A POSTROUTING -o enp2s0 -s 192.168.14.32/27 -j MASQUERADE --random enp2s0 is the public interface on A. This iptable rule is to provide internet to the computers in the private network. A ping from A to B trigger the oops: ping 192.168.3.2. If the tunnel was in ipv4, the ping just print nothing, as if the packet is dropped internally, I think this is what I supposed to get instead of the oops. This oops seems in fact a misconfiguration on iptables: I have to not masquerading packets that are subject to be processed by ipsec. If I change the rule to: iptables -A POSTROUTING -s 192.168.14.32/27 -o enp2s0 -m policy --dir out --pol none -j MASQUERADE --random, all is working properly. you should also check 3.9 and perhaps some 3.10-rc and if the problem is still there, report this to the kernel devs. (In reply to Veovis from comment #4) > No, it doesn't. (vanilla 3.8.6, same .config) I'm pushing this to the people handling the vanilla kernel. (In reply to PaX Team from comment #6) > you should also check 3.9 and perhaps some 3.10-rc and if the problem is > still there, report this to the kernel devs. Please do this first (3.9.7 / 3.10-rc7) so we know if upstream has already fixed this; if not fixed, I will look into the code in two days from now. Thanks for correcting my report. I am in vacation right now, so I cannot test the newest kernel until july 8. I reported the bug on the netdev ML, but it had not received any comment so far. I have seen a bug very close to mine a couple of weeks ago, that received some patchs. I'm testing sys-kernel/hardened-sources-3.9.9 on my buggy systems. It seems this precise bug is solved, since from this version at least. I have still kernel panics caused by ipsec kernel code on recent kernels (3.8 and 3.9 branches until 3.9.5 at least), but this is another bug. I'll refer to you if I get the kernel trace. not anymore in the tree. @Veovis: work for you the latest version of 3.10/3.11 ? (In reply to Agostino Sarubbo from comment #11) > @Veovis: work for you the latest version of 3.10/3.11 ? @Veovis: Please test the latest versions. Hi, Right now, I have 3 systems on 3.10.1-hardened-r1, but with a small uptime (48 hours only). No kernel panic to report yet. Probably unrelated (or specific to my hoster maybe), but if I use IPv6-IPSec for tunneling, I have a lot of connection problems (ping OK, but connection between exchange server <=> active directory is not, lots of 0-length packets) With a IPv4-IPSEC, all is fine. |
