lkml.org 
[lkml]   [1999]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectcalling skb_queue_purge() causes oops when called from FreeS/WAN under 2.2.x
Beg of your time to help debug this bewildering bug...

I am in the process of implementing PF_KEYv2 sockets in the kernel.
It is a socket interface between one or more userspace keying daemons
and a key-consuming kernel in the same machine. I had previously
gotten it to work under 2.0.36 kernels. I notice there are
significant changes in the kernel socket implementation support from
2.0.xx to 2.2.xx.

I thought I had figured out everything to change, but I'm having
problems with closing sockets from userspace. When I close a socket
from userspace, the kernel machinery calls pfkey_release(), similarly
to most other socket drivers. I used af_unix, af_appletalk,
af_inet/udp, af_netlink as examples. First, I check sk->dead, then
call sk->state_change(), then call sklist_remove_socket() to take it
out of the socket list, then try to dequeue all of the skb's from
sk->receive_queue and kfree_skb() any that I find. At this point it
will oops with:

Unable to handle kernel NULL pointer dereference at virtual address 00000008
current->tss.cr3 = 0052e000, %cr3 = 0052e000
*pde = 00000000.
Entering kdb due to panic @ 0xc011e768
eax = 0xc17ea97c ebx = 0xc1fff080 ecx = 0x00000000 edx = 0xc1d48c40
esi = 0xc17ea940 edi = 0x00000202 esp = 0xc1d292a0 eip = 0xc011e768
ebp = 0xc073fee4 ss = 0xc1d48c40 cs = 0x00000010 eflags = 0x00010082
ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff &regs = 0xc073fe98
kdb> bt
EBP EIP Function(args)
0xc073fee4 0xc011e768 kfree+0x74( 0xc17ea940)
0xc073fef4 0xc01504b9 kfree_skbmem+0x25( 0xc1d292a0)
0xc073ff08 0xc0150581 __kfree_skb+0xa5( 0xc1d292a0)
0xc073ff1c 0xc014ff40 sklist_destroy_socket+0x60( 0xc284c540, 0xc1d48c40, 0xc042919c, 0xc0429100, 0xc073ff48)
0xc073ff34 0xc283c404 ipsec_rcv+0x1e60( 0xc042919c, 0x0)
0xc073ff48 0xc014dead sock_release+0x21( 0xc042919c)
0xc073ff58 0xc014e24b sock_close+0x27( 0xc0429100, 0xc0f13920)
0xc073ff74 0xc0122579 __fput+0x21( 0xc0f13920, 0xc0f13920)
0xc073ff88 0xc0123671 fput+0x19( 0xc0f13920)
0xc073ffa0 0xc01225f5 filp_close+0x51( 0xc0f13920, 0xc1e8e2a0)
0xc073ffbc 0xc0122661 sys_close+0x5d( 0x3, 0x80503b0, 0x4, 0x8050420, 0x804cae3)
0xbffff928 0xc0107b18 system_call
kdb> id 0xc011e768
kfree+0x74: movl 0x8(%ecx),%edx
kfree+0x77: movl %edx,0xfffffffc(%ebp)
kfree+0x7a: cmpl $0xa5c32f2b,%edx
kfree+0x80: jne kfree+0x154
kfree+0x86: movl 0xc(%ecx),%eax
kfree+0x89: movl %eax,0xfffffffc(%ebp)
kfree+0x8c: testl %eax,%eax
kfree+0x8e: je kfree+0x10c
kfree+0x90: decl %eax
kfree+0x91: movl %eax,0xc(%ecx)
kfree+0x94: movl (%ecx),%edx
kfree+0x96: movl 0xfffffff8(%ebp),%eax
kfree+0x99: movl %edx,(%eax)
kfree+0x9b: movl %eax,(%ecx)
kfree+0x9d: cmpl $0x0,(%eax)
kfree+0xa0: je kfree+0xe0


I am really baffled by this. It always comes up with the same first
line, which I don't completely understand:
Unable to handle kernel NULL pointer dereference at virtual address 00000008

What baffles me even more is the fact that it works fine under 2.0.xx
and the other examples in the 2.2.x kernel seem to work fine too. I
have compared initialisation code on all these as well to see if I am
forgetting something, but have run out of ideas.

Unfortunately I have to caution people about U.S. crypto-export
restrictions. If you are a U.S. citizen or are in the U.S. please be
careful what you post. Please send responses to this list.

For those with a curiosity, the code is at:

ftp.xs4all.nl/pub/crypto/freeswan/snapshot.tar.gz

in file:

klips/net/ipsec/pfkey_v2.c

A sampling of the contents of the offending skb's look something like:

Oct 22 21:34:11 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f080 stamp:0.536577 dev:c01defd8 dev->name:lo h:c1e0a820 nh:c0d3486c mac:c0d3485e dst:00000000 len:2 csum:-665534469 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1e0a820 data:c1e0a820 tail:c1e0a822 end:c1e0a830 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b2:17: 0: 0 destructor:c014fb6c

Oct 22 21:36:30 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6fb80 stamp:0.993496 dev:c01defd8 dev->name:lo h:c1a0a260 nh:c0d34cec mac:c0d34cde dst:00000000 len:10 csum:-1981392342 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1a0a260 data:c1a0a260 tail:c1a0a26a end:c1a0a270 data: 2: 3: 0: 9: a: 0: 0: 0: 1: 0: 0: 0:fa:18: 0: 0 destructor:c014fb6c

Oct 24 16:40:17 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f340 stamp:0.94254 dev:c01deef8 dev->name:eth0 h:c1f87900 nh:c03efca0 mac:c03efc92 dst:00000000 len:2 csum:1808618379 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:1544 security:0 truesize:16 head:c1f87900 data:c1f87900 tail:c1f87902 end:c1f87910 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:39:22: 0: 0 destructor:c014fb6c

Oct 24 16:40:29 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f600 stamp:0.373500 dev:c01defd8 dev->name:lo h:c17dc340 nh:c1fbdbcc mac:c1fbdbbe dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c17dc340 data:c17dc340 tail:c17dc342 end:c17dc350 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:f8:22: 0: 0 destructor:c014fb6c

Oct 24 16:54:53 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c03fac40 stamp:0.786748 dev:c01deef8 dev->name:eth0 h:c1591100 nh:c03ff400 mac:c03ff3f2 dst:00000000 len:2 csum:759554798 used:1 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:1544 security:0 truesize:16 head:c1591100 data:c1591100 tail:c1591102 end:c1591110 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b4:24: 0: 0 destructor:c014fb6c

Oct 24 16:58:40 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c1febd00 stamp:0.0 dev:00000000 dev->name:NULL h:c14733e0 nh:00000000 mac:00000000 dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:0 security:0 truesize:16 head:c14733e0 data:c14733e0 tail:c14733e2 end:c14733f0 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b1: 1: 0: 0 destructor:c014fb6c

Oct 25 11:46:22 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c08bd6c0 stamp:0.31530 dev:c01defd8 dev->name:lo h:c1473920 nh:c1113f10 mac:c1113f02 dst:00000000 len:2 csum:1885630317 used:114 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1473920 data:c1473920 tail:c1473922 end:c1473930 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:2d: 7: 0: 0 destructor:c014fb6c

Oct 25 11:49:07 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c1febd00 stamp:0.0 dev:00000000 dev->name:NULL h:c14733e0 nh:00000000 mac:00000000 dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:0 security:0 truesize:16 head:c14733e0 data:c14733e0 tail:c14733e2 end:c14733f0 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b1: 1: 0: 0 destructor:c014fb6c

There is always one packet in the queue and it usually has a size of
2, 8 or 16.

I have my doubts about the ownership of these packets. The packets we
deal with are 80, 104, 112 octets, never 2! The other thing that
bothers me is that there seems to be a device associated with them,
such as loopback or eth0. The loopback device makes some sense, but
eth0 definitely does not.

Why might these packets be ending up in our receive queue?

Why are they so small?

Why are they crashing kfree_skb()?

Any insights would be most helpful.


slainte mhath, RGB
--
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.062 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site