[Openswan Users] openswan 2.6.33 rmmod ipsec cause kernel oops of null pointer

David McCullough david_mccullough at mcafee.com
Wed Mar 30 23:02:04 EDT 2011


Jivin Zhiping Liu lays it down ...
> produced by following:

Thanks for that,  we are doing a double ipsec_dev_put which I think is the
problem.  try the attached patch and see how that goes.

Cheers,
Davidm

> 1.kernel version: latest stable 2.6.38.1
> 
> PL-SMS ~ # uname -r
> 2.6.38.1
> PL-SMS ~ # 
> 
> 2.ipsec config file:
> 
> PL-SMS openswan-2.6.33 # cat /etc/ipsec.conf 
> # /etc/ipsec.conf - Openswan IPsec configuration file
> 
> # This file:  /usr/local/share/doc/openswan/ipsec.conf-sample
> #
> # Manual:     ipsec.conf.5
> 
> 
> version 2.0     # conforms to second version of ipsec.conf specification
> 
> # basic configuration
> config setup
>       # Do not set debug options to debug configuration issues!
>       # plutodebug / klipsdebug = "all", "none" or a combation from below:
>       # "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
>       # eg:
>       # plutodebug="control parsing"
>       #
>       # enable to get logs per-peer
>       # plutoopts="--perpeerlog"
>       #
>       # Again: only enable plutodebug or klipsdebug when asked by a developer
>       #
>       # NAT-TRAVERSAL support, see README.NAT-Traversal
>       nat_traversal=yes
>       # exclude networks used on server side by adding %v4:!a.b.c.0/24
>       virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>       # OE is now off by default. Uncomment and change to on, to enable.
>       oe=off
>       # which IPsec stack to use. auto will try netkey, then klips then mast
>       protostack=mast
> 
> 
> # Add connections here
> 
> # sample VPN connection
> # for more examples, see /etc/ipsec.d/examples/
> #conn sample
> #      # Left security gateway, subnet behind it, nexthop toward right.
> #      left=10.0.0.1
> #      leftsubnet=172.16.0.0/24
> #      leftnexthop=10.22.33.44
> #      # Right security gateway, subnet behind it, nexthop toward left.
> #      right=10.12.12.1
> #      rightsubnet=192.168.0.0/24
> #      rightnexthop=10.101.102.103
> #      # To authorize this connection, but not actually start it, 
> #      # at startup, uncomment this.
> #      #auto=add
> 
> PL-SMS openswan-2.6.33 # 
> 
> 3.how to produce kernel oops
> 
> 
> PL-SMS ~ # modprobe ipsec
> PL-SMS ~ # rmmod ipsec
> Killed
> PL-SMS ~ # lsmod 
> Module                  Size  Used by
> ipsec                 311608  0 
> PL-SMS ~ # 
> 
> 4.kernel dmesg shows:
> 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: [<f8101a59>] ipsec_mast_cleanup_devices+0x2f/0x4a [ipsec]
> *pde = 00000000 
> Oops: 0002 [#1] 
> last sysfs file: /sys/devices/virtual/net/ipsec0/address
> Modules linked in: ipsec(-)
> 
> Pid: 3387, comm: rmmod Not tainted 2.6.38.1 #5 System manufacturer System Product Name/M2A-VM
> EIP: 0060:[<f8101a59>] EFLAGS: 00010246 CPU: 0
> EIP is at ipsec_mast_cleanup_devices+0x2f/0x4a [ipsec]
> EAX: 00000000 EBX: 00000000 ECX: f5b1bef8 EDX: 00000001
> ESI: 00000000 EDI: 00000880 EBP: f5b1bf2c ESP: f5b1bf28
>  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Process rmmod (pid: 3387, ti=f5b1a000 task=f5f14c80 task.ti=f5b1a000)
> Stack:
>  f813aa40 f5b1bf4c f80f4013 f5b1bf54 f5b1bf4c c103aa8b f813aa40 00000000
>  00000880 f5b1bfac c103a479 65737069 00000063 f5b2edc0 f5b1bf70 c10599db
>  f5b2edc0 f5eb9380 f5b1bf9c c105a315 ffffffff b77aa000 b77ab000 f5b2ecc4
> Call Trace:
>  [<f80f4013>] cleanup_module+0x13/0x12a [ipsec]
>  [<c103aa8b>] ? __try_stop_module+0xf/0x4c
>  [<c103a479>] sys_delete_module+0x17c/0x1cf
>  [<c10599db>] ? remove_vma+0x41/0x47
>  [<c105a315>] ? do_munmap+0x1de/0x20c
>  [<c1002710>] sysenter_do_call+0x12/0x26
> Code: 31 db eb 35 8b 14 9d 60 c0 13 f8 85 d2 74 29 8b 82 d8 01 00 00 ff 08 89 d0 e8 c7 57 18 c9 8b 04 9d 60 c0 13 f8 8b 80 d8 01 00 00 <ff> 08 c7 04 9d 60 c0 13 f8 00 00 00 00 43 3b 1d e8 8c 13 f8 7e 
> EIP: [<f8101a59>] ipsec_mast_cleanup_devices+0x2f/0x4a [ipsec] SS:ESP 0068:f5b1bf28
> CR2: 0000000000000000
> ---[ end trace 01ae9d869f653d55 ]---
> PL-SMS ~ # 
> 
> thanks for you reply!
> 
> 2011/3/31 David McCullough <david_mccullough at mcafee.com>
> 
> 
> 	Jivin Zhiping Liu lays it down ...
> 	
> 	> Hi all:
> 	>
> 	> I don't know if anyone have found out this before,but it's obviously a bug in file: linux/net/ipsec/ipsec_mast.c
> 	>
> 	>
> 	> 1085 int
> 	> 1086 ipsec_mast_init_devices(void)
> 	> 1087 {
> 	> 1088         /*
> 	> 1089          * mast0 is used for transport mode stuff, and generally is
> 	> 1090          * the default unless the user decides to create more.
> 	> 1091          */
> 	> 1092         ipsec_mast_createnum(0);
> 	> 1093
> 	> 1094         return 0;
> 	> 1095 }
> 	>
> 	> line 1092 set mast device num (mastdevices_max) to 0.
> 	>
> 	> if we do a rmmod ipsec now ,in ipsec_mast_cleanup_devices
> 	>
> 	> 1098 int
> 	> 1099 ipsec_mast_cleanup_devices(void)
> 	> 1100 {
> 	> 1101         int error = 0;
> 	> 1102         int i;
> 	> 1103         struct net_device *dev_mast;
> 	> 1104
> 	> 1105         for(i = 0; i <= mastdevices_max; i++) {
> 	> 1106                 if(mastdevices[i]!=NULL) {
> 	> 1107                         dev_mast = mastdevices[i];
> 	> 1108                         //lzp add
> 	> 1109                         if (!dev_mast)
> 	> 1110                                 printk(KERN_WARNING "dev_mast null");
> 	> 1111                         ipsec_dev_put(dev_mast);
> 	> 1112                         unregister_netdev(dev_mast);
> 	> 1113 #ifndef alloc_netdev
> 	> 1114                         kfree(dev_mast->priv);
> 	> 1115                         dev_mast->priv=NULL;
> 	> 1116 #endif
> 	> 1117                         ipsec_dev_put(mastdevices[i]);
> 	> 1118                         mastdevices[i]=NULL;
> 	> 1119                 }
> 	> 1120         }
> 	> 1121         return error;
> 	> 1122 }
> 	>
> 	> we will clean up mastdevices[0],which is not initialize yet.
> 	
> 	
> 	It will be initialised because ipsec_mast_createnum initialises it.
> 	
> 	The code at 1106 checks if it's non-NULL before cleaning it up,  so this is
> 	safe also as mastdevices will be initialised to all 0's, and we always set it
> 	back to NULL when we clean up.
> 	
> 
> 	> change to this fix the problem
> 	> 1085 int
> 	> 1086 ipsec_mast_init_devices(void)
> 	> 1087 {
> 	> 1088         /*
> 	> 1089          * mast0 is used for transport mode stuff, and generally is
> 	> 1090          * the default unless the user decides to create more.
> 	> 1091          */
> 	> 1092         ipsec_mast_createnum(-1);
> 	> 1093
> 	> 1094         return 0;
> 	> 1095 }
> 	
> 	
> 	This will almost certainly cause a problem as we will index into mastdevices
> 	with -1 which is bad.
> 	
> 	Do you have a kernel oops that points to a problem here?  That might helps
> 	because as it stands I don't see a problem with that particular code path,
> 	
> 	Cheers,
> 	Davidm
> 	
> 	
> 	--
> 	David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
> 	McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
> 	
> 
> 
> 
> 
> -- 
> 
> 
> 

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mast_rmmod.diff
Type: text/x-diff
Size: 587 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20110331/f2566d3e/attachment-0001.bin 


More information about the Users mailing list