querying an snmp daemon runnin on a system with openswan for interface information results in a kernel oops. Reproducible: Always Steps to Reproduce: boot, configure at least one ipsec interface, start snmp daemon, snmpwalk localhost interfaces Actual Results: kernel oops Expected Results: information about interface returned Unable to handle kernel NULL pointer dereference at virtual address 000000ec d08bdcf6 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<d08bdcf6>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: cd675f68 ecx: 00000000 edx: cd675f04 esi: 00000000 edi: cd675f14 ebp: cf003000 esp: cd675ef4 ds: 0018 es: 0018 ss: 0018 Process snmpd (pid: 2436, stackpage=cd675000) Stack: cd675f04 cd675f64 cfe43800 cf154ea0 da0110e9 00000000 00000000 00000000 000089f0 cf003000 cd675f54 cd675f54 c021ec5f cf003000 cd675f54 000089f0 00000000 000089f0 00000001 00000000 c021ee8a cd675f54 000089f0 00000020 Call Trace: [<c021ec5f>] [<c021ee8a>] [<c0216576>] [<c0144ef9>] [<c010729b>] Code: ff 0d ec 00 00 00 0f 94 c0 84 c0 75 0a b8 fa ff ff ff e9 fd >>EIP; d08bdcf6 <[ipsec]ipsec_tunnel_ioctl+146/240> <===== >>ebx; cd675f68 <_end+d318d14/104f8e0c> >>edx; cd675f04 <_end+d318cb0/104f8e0c> >>edi; cd675f14 <_end+d318cc0/104f8e0c> >>ebp; cf003000 <_end+eca5dac/104f8e0c> >>esp; cd675ef4 <_end+d318ca0/104f8e0c> Trace; c021ec5f <dev_ifsioc+3cf/440> Trace; c021ee8a <dev_ioctl+1ba/2a0> Trace; c0216576 <sock_ioctl+26/30> Trace; c0144ef9 <sys_ioctl+c9/250> Trace; c010729b <system_call+33/38> Code; d08bdcf6 <[ipsec]ipsec_tunnel_ioctl+146/240> 00000000 <_EIP>: Code; d08bdcf6 <[ipsec]ipsec_tunnel_ioctl+146/240> <===== 0: ff 0d ec 00 00 00 decl 0xec <===== Code; d08bdcfc <[ipsec]ipsec_tunnel_ioctl+14c/240> 6: 0f 94 c0 sete %al Code; d08bdcff <[ipsec]ipsec_tunnel_ioctl+14f/240> 9: 84 c0 test %al,%al Code; d08bdd01 <[ipsec]ipsec_tunnel_ioctl+151/240> b: 75 0a jne 17 <_EIP+0x17> Code; d08bdd03 <[ipsec]ipsec_tunnel_ioctl+153/240> d: b8 fa ff ff ff mov $0xfffffffa,%eax Code; d08bdd08 <[ipsec]ipsec_tunnel_ioctl+158/240> 12: e9 fd 00 00 00 jmp 114 <_EIP+0x114> Problem occurs when snmpd tries to figure out transmission speed for the interfaces: <agent/mibgroup/mibII/interfaces.c> ... if (ioctl(fd, 0x8947, &ifr) >= 0) { new_ioctl_nums = 1; } else if (ioctl(fd, SIOCDEVPRIVATE, &ifr) >= 0) { new_ioctl_nums = 0; ... So, it first tries SIOCGMIIREG ioctl; if that doesn't work, it falls back to SIOCDEVPRIVATE which seems to have been previously used for this purpose. ipsec however uses SIOCDEVPRIVATE completely differently: /* attach a virtual ipsec? device to a physical device */ #define IPSEC_SET_DEV (SIOCDEVPRIVATE) ==> Result: ipsec bombs out trying to handle SIOCDEVPRIVATE ioctl for (already configured) ipsec0. which leaves us with the question: what's the right fix? a) remove the fallback SIOCDEVPRIVATE call from snmpd b) add a SIOCGMIIREG ioctl to ipsec c) handle the spurious SIOCDEVPRIVATE ioctl more gracefully in ipsec. I've just verified that removing the fallback to SIOCDEVPRIVATE from snmp works as a fix, no more problems with openswan+snmp daemon. What I can't say if this might impact snmpd functionality when used with older kernels/drivers that implement only SIOCDEVPRIVATE.
This is not a Gentoo specific bug. Reference here: http://lists.openswan.org/pipermail/users/2004-July/001759.html I will be looking for a fix and applying it when it is ready. Have a good one, Jay
Jay, hope you don't mind if I leave this one to you. Once a fix is available, send a patch to plasmaroo and he'll consider it for gentoo-sources. Thanks.
Has been fixed in openswan CVS, see http://bugs.xelerance.com/view.php?id=144
Some meore info since http://bugs.xelerance.com/view.php?id=144 is down ATM: fixed in version 1.226 of ipsec_tunnel.c; it's a 1-line change, see http://anoncvs.openswan.org/cgi-bin/viewcvs.cgi/openswan-2/linux/net/ipsec/ipsec_tunnel.c?r1=1.225&r2=1.226 for the relevant diff
openswan-2.3.0 is in portage and should resolve this issue.
