[Openswan Users] openswan 2.6.33 rmmod ipsec cause kernel oops of null pointer
Zhiping Liu
flyingzpl at gmail.com
Wed Mar 30 22:41:36 EDT 2011
produced by following:
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
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110331/a5a06268/attachment.html
More information about the Users
mailing list