net: nfc: BUG and panic in accept() on 3.5-rc2

net: nfc: BUG and panic in accept() on 3.5-rc2

[Sasha Levin]

Hi all,

I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:

[ 2136.383310] BUG: unable to handle kernel NULL pointer dereference at 00000000000003b0
[ 2136.384022] IP: [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
[ 2136.384022] PGD 131c4067 PUD 11c0c067 PMD 0 
[ 2136.388106] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 2136.388106] CPU 1 
[ 2136.388106] Pid: 24855, comm: trinity-child1 Tainted: G        W    3.5.0-rc2-sasha-00015-g7b268f7 #374  
[ 2136.388106] RIP: 0010:[<ffffffff8114e400>]  [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
[ 2136.388106] RSP: 0018:ffff8800130b3ca8  EFLAGS: 00010046
[ 2136.388106] RAX: 0000000000000086 RBX: ffff88001186b000 RCX: 0000000000000000
[ 2136.388106] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 2136.388106] RBP: ffff8800130b3d08 R08: 0000000000000001 R09: 0000000000000000
[ 2136.388106] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000002
[ 2136.388106] R13: 00000000000003b0 R14: 0000000000000000 R15: 0000000000000000
[ 2136.388106] FS:  00007fa5b1bd4700(0000) GS:ffff88001b800000(0000) knlGS:0000000000000000
[ 2136.388106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2136.388106] CR2: 00000000000003b0 CR3: 0000000011d1f000 CR4: 00000000000406e0
[ 2136.388106] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2136.388106] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2136.388106] Process trinity-child1 (pid: 24855, threadinfo ffff8800130b2000, task ffff88001186b000)
[ 2136.388106] Stack:
[ 2136.388106]  ffff8800130b3cd8 ffffffff81121785 ffffffff81236774 000080d000000001
[ 2136.388106]  ffff88001b9d6c00 00000000001d6c00 ffffffff130b3d08 ffff88001186b000
[ 2136.388106]  0000000000000000 0000000000000002 0000000000000000 0000000000000000
[ 2136.388106] Call Trace:
[ 2136.388106]  [<ffffffff81121785>] ? sched_clock_local+0x25/0x90
[ 2136.388106]  [<ffffffff81236774>] ? get_empty_filp+0x74/0x220
[ 2136.388106]  [<ffffffff8114e97a>] lock_acquire+0x18a/0x1e0
[ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff837c0ef0>] _raw_write_lock_bh+0x40/0x80
[ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff836b37df>] rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff8321cfe8>] sock_release+0x18/0x70
[ 2136.388106]  [<ffffffff8321d069>] sock_close+0x29/0x30
[ 2136.388106]  [<ffffffff81236bca>] __fput+0x11a/0x2c0
[ 2136.388106]  [<ffffffff81236d85>] fput+0x15/0x20
[ 2136.388106]  [<ffffffff8321de34>] sys_accept4+0x1b4/0x200
[ 2136.388106]  [<ffffffff837c165c>] ? _raw_spin_unlock_irq+0x4c/0x80
[ 2136.388106]  [<ffffffff837c1669>] ? _raw_spin_unlock_irq+0x59/0x80
[ 2136.388106]  [<ffffffff837c2565>] ? sysret_check+0x22/0x5d
[ 2136.388106]  [<ffffffff8321de8b>] sys_accept+0xb/0x10
[ 2136.388106]  [<ffffffff837c2539>] system_call_fastpath+0x16/0x1b
[ 2136.388106] Code: ec 04 00 0f 85 ea 03 00 00 be d5 0b 00 00 48 c7 c7 8a c1 40 84 e8 b1 a5 f8 ff 31 c0 e9 d4 03 00 00 66 2e 0f 1f 84 00 00 00 00 00 <49> 81 7d 00 60 73 5e 85 b8 01 00 00 00 44 0f 44 e0 83 fe 01 77 
[ 2136.388106] RIP  [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
[ 2136.388106]  RSP <ffff8800130b3ca8>
[ 2136.388106] CR2: 00000000000003b0
[ 2136.388106] ---[ end trace 6d450e935ee18982 ]---
[ 2136.388106] Kernel panic - not syncing: Fatal exception in interrupt

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Eric Dumazet]

On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> Hi Sasha,
> 
> On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > Hi all,
> > 
> > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > 
> Thanks for the report, it could be worth adding this one to
> bugzilla.kernel.org.
> 
> What's trinity ?
> Also, if this one is reproducible, would you mind sharing some details about
> how we could reproduce it ?

Well, bugfix should be trivial enough ;)

diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c
index ec1134c..208416e 100644
--- a/net/nfc/rawsock.c
+++ b/net/nfc/rawsock.c
@@ -54,11 +54,12 @@ static int rawsock_release(struct socket *sock)
 {
 	struct sock *sk = sock->sk;
 
-	pr_debug("sock=%p\n", sock);
-
-	sock_orphan(sk);
-	sock_put(sk);
+	pr_debug("sock=%p sk=%p\n", sock, sk);
 
+	if (sk) {
+		sock_orphan(sk);
+		sock_put(sk);
+	}
 	return 0;
 }
 

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Samuel Ortiz]

Hi Sasha,

On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> Hi all,
> 
> I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> 
Thanks for the report, it could be worth adding this one to
bugzilla.kernel.org.

What's trinity ?
Also, if this one is reproducible, would you mind sharing some details about
how we could reproduce it ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Sasha Levin]

On Mon, 2012-06-11 at 16:41 +0200, Eric Dumazet wrote:
> On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> > Hi Sasha,
> > 
> > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > > Hi all,
> > > 
> > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > > 
> > Thanks for the report, it could be worth adding this one to
> > bugzilla.kernel.org.
> > 
> > What's trinity ?
> > Also, if this one is reproducible, would you mind sharing some details about
> > how we could reproduce it ?
> 
> Well, bugfix should be trivial enough ;)
> 
> diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c
> index ec1134c..208416e 100644
> --- a/net/nfc/rawsock.c
> +++ b/net/nfc/rawsock.c
> @@ -54,11 +54,12 @@ static int rawsock_release(struct socket *sock)
>  {
>  	struct sock *sk = sock->sk;
>  
> -	pr_debug("sock=%p\n", sock);
> -
> -	sock_orphan(sk);
> -	sock_put(sk);
> +	pr_debug("sock=%p sk=%p\n", sock, sk);
>  
> +	if (sk) {
> +		sock_orphan(sk);
> +		sock_put(sk);
> +	}
>  	return 0;
>  }

Eric, Is there something that documents at what state each of the
callbacks in the network subsystem can be called? Like a big flow chart
of some sorts?

I'm asking because I've looked at this as well before sending this mail,
and while the fix does look trivial, I wasn't sure whether it is really
the correct fix, or the problem is that this callback wasn't supposed be
called at all so something else is broken (we had such issue with
namespaces and unshare() not long ago).

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Samuel Ortiz]

Hi Eric,

On Mon, Jun 11, 2012 at 04:41:33PM +0200, Eric Dumazet wrote:
> On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> > Hi Sasha,
> > 
> > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > > Hi all,
> > > 
> > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > > 
> > Thanks for the report, it could be worth adding this one to
> > bugzilla.kernel.org.
> > 
> > What's trinity ?
> > Also, if this one is reproducible, would you mind sharing some details about
> > how we could reproduce it ?
> 
> Well, bugfix should be trivial enough ;)
Yep, I looked at the code only after looking at Sasha's report.

Thanks for the patch, do you mind if I add your SOB to it ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Eric Dumazet]

On Mon, 2012-06-11 at 16:50 +0200, Sasha Levin wrote:

> Eric, Is there something that documents at what state each of the
> callbacks in the network subsystem can be called? Like a big flow chart
> of some sorts?
> 
> I'm asking because I've looked at this as well before sending this mail,
> and while the fix does look trivial, I wasn't sure whether it is really
> the correct fix, or the problem is that this callback wasn't supposed be
> called at all so something else is broken (we had such issue with
> namespaces and unshare() not long ago).
> 

I am not aware of such 'document'.

Things change, and only *good* reference is actual source code.

Now, take a look at sock_graft()/sock_orphan()/inet_release() ...

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Eric Dumazet]

On Mon, 2012-06-11 at 16:57 +0200, Samuel Ortiz wrote:
> Hi Eric,
> 
> On Mon, Jun 11, 2012 at 04:41:33PM +0200, Eric Dumazet wrote:
> > On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> > > Hi Sasha,
> > > 
> > > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > > > Hi all,
> > > > 
> > > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > > > 
> > > Thanks for the report, it could be worth adding this one to
> > > bugzilla.kernel.org.
> > > 
> > > What's trinity ?
> > > Also, if this one is reproducible, would you mind sharing some details about
> > > how we could reproduce it ?
> > 
> > Well, bugfix should be trivial enough ;)
> Yep, I looked at the code only after looking at Sasha's report.
> 
> Thanks for the patch, do you mind if I add your SOB to it ?

I would prefer making sure it fixes the bug first ;)

Thanks

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Dave Jones]

On Mon, Jun 11, 2012 at 04:41:34PM +0200, Samuel Ortiz wrote:
 > Hi Sasha,
 > 
 > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
 > > Hi all,
 > > 
 > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
 > > 
 > Thanks for the report, it could be worth adding this one to
 > bugzilla.kernel.org.
 > 
 > What's trinity ?

http://codemonkey.org.uk/projects/trinity/

	Dave

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Samuel Ortiz]

On Mon, Jun 11, 2012 at 04:59:38PM +0200, Eric Dumazet wrote:
> On Mon, 2012-06-11 at 16:57 +0200, Samuel Ortiz wrote:
> > Hi Eric,
> > 
> > On Mon, Jun 11, 2012 at 04:41:33PM +0200, Eric Dumazet wrote:
> > > On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> > > > Hi Sasha,
> > > > 
> > > > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > > > > Hi all,
> > > > > 
> > > > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > > > > 
> > > > Thanks for the report, it could be worth adding this one to
> > > > bugzilla.kernel.org.
> > > > 
> > > > What's trinity ?
> > > > Also, if this one is reproducible, would you mind sharing some details about
> > > > how we could reproduce it ?
> > > 
> > > Well, bugfix should be trivial enough ;)
> > Yep, I looked at the code only after looking at Sasha's report.
> > 
> > Thanks for the patch, do you mind if I add your SOB to it ?
> 
> I would prefer making sure it fixes the bug first ;)
Sure, although your patch makes sense regardless of that :)
I'll still wait for Sasha to confirm that it fixes his crash.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Sasha Levin]

On Mon, 2012-06-11 at 16:58 +0200, Eric Dumazet wrote:
> On Mon, 2012-06-11 at 16:50 +0200, Sasha Levin wrote:
> 
> > Eric, Is there something that documents at what state each of the
> > callbacks in the network subsystem can be called? Like a big flow chart
> > of some sorts?
> > 
> > I'm asking because I've looked at this as well before sending this mail,
> > and while the fix does look trivial, I wasn't sure whether it is really
> > the correct fix, or the problem is that this callback wasn't supposed be
> > called at all so something else is broken (we had such issue with
> > namespaces and unshare() not long ago).
> > 
> 
> I am not aware of such 'document'.
> 
> Things change, and only *good* reference is actual source code.
> 
> Now, take a look at sock_graft()/sock_orphan()/inet_release() ...

I see.

I grepped for release callbacks and the first few in the result (atm,
ax_25) did check for !sk, so I guess I'll just follow what I see in
other code in the future :)

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Sasha Levin]

On Mon, 2012-06-11 at 17:20 +0200, Samuel Ortiz wrote:
> On Mon, Jun 11, 2012 at 04:59:38PM +0200, Eric Dumazet wrote:
> > On Mon, 2012-06-11 at 16:57 +0200, Samuel Ortiz wrote:
> > > Hi Eric,
> > > 
> > > On Mon, Jun 11, 2012 at 04:41:33PM +0200, Eric Dumazet wrote:
> > > > On Mon, 2012-06-11 at 16:41 +0200, Samuel Ortiz wrote:
> > > > > Hi Sasha,
> > > > > 
> > > > > On Mon, Jun 11, 2012 at 04:00:41PM +0200, Sasha Levin wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > I've stumbled on the following while fuzzing with trinity inside a KVM tools guest, running on 3.5-rc2:
> > > > > > 
> > > > > Thanks for the report, it could be worth adding this one to
> > > > > bugzilla.kernel.org.
> > > > > 
> > > > > What's trinity ?
> > > > > Also, if this one is reproducible, would you mind sharing some details about
> > > > > how we could reproduce it ?
> > > > 
> > > > Well, bugfix should be trivial enough ;)
> > > Yep, I looked at the code only after looking at Sasha's report.
> > > 
> > > Thanks for the patch, do you mind if I add your SOB to it ?
> > 
> > I  would prefer making sure it fixes the bug first ;)
> Sure, although your patch makes sense regardless of that :)
> I'll still wait for Sasha to confirm that it fixes his crash.

I don't have a direct way of reproducing it, but I've put it in the test
vm and the fuzzer is running, I'll let you know tomorrow if it happened
again.

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Dave Jones]

On Mon, Jun 11, 2012 at 06:56:50PM +0200, Sasha Levin wrote:

 > > > > > > What's trinity ?
 > > > > > > Also, if this one is reproducible, would you mind sharing some details about
 > > > > > > how we could reproduce it ?
 > > > > > 
 > > > > > Well, bugfix should be trivial enough ;)
 > > > > Yep, I looked at the code only after looking at Sasha's report.
 > > > > 
 > > > > Thanks for the patch, do you mind if I add your SOB to it ?
 > > > 
 > > > I  would prefer making sure it fixes the bug first ;)
 > > Sure, although your patch makes sense regardless of that :)
 > > I'll still wait for Sasha to confirm that it fixes his crash.
 > 
 > I don't have a direct way of reproducing it, but I've put it in the test
 > vm and the fuzzer is running, I'll let you know tomorrow if it happened
 > again.

You might be able to trigger it faster by using -P PF_NFC, which will 
force trinity to only use NFC sockets.

sidenote: most protocols trigger the module to be auto-loaded when a socket
is created. This doesn't seem to happen with nfc, making me need to manually
modprobe it first. Intentional ?

	Dave

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Samuel Ortiz]

Hi Dave,

On Mon, Jun 11, 2012 at 01:25:45PM -0400, Dave Jones wrote:
> On Mon, Jun 11, 2012 at 06:56:50PM +0200, Sasha Levin wrote:
> 
>  > > > > > > What's trinity ?
>  > > > > > > Also, if this one is reproducible, would you mind sharing some details about
>  > > > > > > how we could reproduce it ?
>  > > > > > 
>  > > > > > Well, bugfix should be trivial enough ;)
>  > > > > Yep, I looked at the code only after looking at Sasha's report.
>  > > > > 
>  > > > > Thanks for the patch, do you mind if I add your SOB to it ?
>  > > > 
>  > > > I  would prefer making sure it fixes the bug first ;)
>  > > Sure, although your patch makes sense regardless of that :)
>  > > I'll still wait for Sasha to confirm that it fixes his crash.
>  > 
>  > I don't have a direct way of reproducing it, but I've put it in the test
>  > vm and the fuzzer is running, I'll let you know tomorrow if it happened
>  > again.
> 
> You might be able to trigger it faster by using -P PF_NFC, which will 
> force trinity to only use NFC sockets.
> 
> sidenote: most protocols trigger the module to be auto-loaded when a socket
> is created. This doesn't seem to happen with nfc, making me need to manually
> modprobe it first. Intentional ?
No, I'm missing the MODULE_ALIAS_NETPROTO() call for NFC. Thanks for the
report.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: net: nfc: BUG and panic in accept() on 3.5-rc2

[Sasha Levin]

On Mon, Jun 11, 2012 at 7:25 PM, Dave Jones <davej@redhat.com> wrote:
> On Mon, Jun 11, 2012 at 06:56:50PM +0200, Sasha Levin wrote:
>
>  > > > > > > What's trinity ?
>  > > > > > > Also, if this one is reproducible, would you mind sharing some details about
>  > > > > > > how we could reproduce it ?
>  > > > > >
>  > > > > > Well, bugfix should be trivial enough ;)
>  > > > > Yep, I looked at the code only after looking at Sasha's report.
>  > > > >
>  > > > > Thanks for the patch, do you mind if I add your SOB to it ?
>  > > >
>  > > > I  would prefer making sure it fixes the bug first ;)
>  > > Sure, although your patch makes sense regardless of that :)
>  > > I'll still wait for Sasha to confirm that it fixes his crash.
>  >
>  > I don't have a direct way of reproducing it, but I've put it in the test
>  > vm and the fuzzer is running, I'll let you know tomorrow if it happened
>  > again.
>
> You might be able to trigger it faster by using -P PF_NFC, which will
> force trinity to only use NFC sockets.
>
> sidenote: most protocols trigger the module to be auto-loaded when a socket
> is created. This doesn't seem to happen with nfc, making me need to manually
> modprobe it first. Intentional ?

It fixes the bug, wasn't been able to reproduce it since then.

[PATCH] net: nfc: fix panic in accept()

[Eric Dumazet]

From: Eric Dumazet <edumazet@google.com>

Sasha Levin reported following panic :

[ 2136.383310] BUG: unable to handle kernel NULL pointer dereference at
00000000000003b0
[ 2136.384022] IP: [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
[ 2136.384022] PGD 131c4067 PUD 11c0c067 PMD 0 
[ 2136.388106] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 2136.388106] CPU 1 
[ 2136.388106] Pid: 24855, comm: trinity-child1 Tainted: G        W
3.5.0-rc2-sasha-00015-g7b268f7 #374  
[ 2136.388106] RIP: 0010:[<ffffffff8114e400>]  [<ffffffff8114e400>]
__lock_acquire+0xc0/0x4b0
[ 2136.388106] RSP: 0018:ffff8800130b3ca8  EFLAGS: 00010046
[ 2136.388106] RAX: 0000000000000086 RBX: ffff88001186b000 RCX:
0000000000000000
[ 2136.388106] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
0000000000000000
[ 2136.388106] RBP: ffff8800130b3d08 R08: 0000000000000001 R09:
0000000000000000
[ 2136.388106] R10: 0000000000000000 R11: 0000000000000001 R12:
0000000000000002
[ 2136.388106] R13: 00000000000003b0 R14: 0000000000000000 R15:
0000000000000000
[ 2136.388106] FS:  00007fa5b1bd4700(0000) GS:ffff88001b800000(0000)
knlGS:0000000000000000
[ 2136.388106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2136.388106] CR2: 00000000000003b0 CR3: 0000000011d1f000 CR4:
00000000000406e0
[ 2136.388106] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 2136.388106] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 2136.388106] Process trinity-child1 (pid: 24855, threadinfo
ffff8800130b2000, task ffff88001186b000)
[ 2136.388106] Stack:
[ 2136.388106]  ffff8800130b3cd8 ffffffff81121785 ffffffff81236774
000080d000000001
[ 2136.388106]  ffff88001b9d6c00 00000000001d6c00 ffffffff130b3d08
ffff88001186b000
[ 2136.388106]  0000000000000000 0000000000000002 0000000000000000
0000000000000000
[ 2136.388106] Call Trace:
[ 2136.388106]  [<ffffffff81121785>] ? sched_clock_local+0x25/0x90
[ 2136.388106]  [<ffffffff81236774>] ? get_empty_filp+0x74/0x220
[ 2136.388106]  [<ffffffff8114e97a>] lock_acquire+0x18a/0x1e0
[ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff837c0ef0>] _raw_write_lock_bh+0x40/0x80
[ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff836b37df>] rawsock_release+0x4f/0xa0
[ 2136.388106]  [<ffffffff8321cfe8>] sock_release+0x18/0x70
[ 2136.388106]  [<ffffffff8321d069>] sock_close+0x29/0x30
[ 2136.388106]  [<ffffffff81236bca>] __fput+0x11a/0x2c0
[ 2136.388106]  [<ffffffff81236d85>] fput+0x15/0x20
[ 2136.388106]  [<ffffffff8321de34>] sys_accept4+0x1b4/0x200
[ 2136.388106]  [<ffffffff837c165c>] ? _raw_spin_unlock_irq+0x4c/0x80
[ 2136.388106]  [<ffffffff837c1669>] ? _raw_spin_unlock_irq+0x59/0x80
[ 2136.388106]  [<ffffffff837c2565>] ? sysret_check+0x22/0x5d
[ 2136.388106]  [<ffffffff8321de8b>] sys_accept+0xb/0x10
[ 2136.388106]  [<ffffffff837c2539>] system_call_fastpath+0x16/0x1b
[ 2136.388106] Code: ec 04 00 0f 85 ea 03 00 00 be d5 0b 00 00 48 c7 c7
8a c1 40 84 e8 b1 a5 f8 ff 31 c0 e9 d4 03 00 00 66 2e 0f 1f 84 00 00 00
00 00 <49> 81 7d 00 60 73 5e 85 b8 01 00 00 00 44 0f 44 e0 83 fe 01 77 
[ 2136.388106] RIP  [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
[ 2136.388106]  RSP <ffff8800130b3ca8>
[ 2136.388106] CR2: 00000000000003b0
[ 2136.388106] ---[ end trace 6d450e935ee18982 ]---
[ 2136.388106] Kernel panic - not syncing: Fatal exception in interrupt

rawsock_release() should test if sock->sk is NULL before calling
sock_orphan()/sock_put()

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 net/nfc/rawsock.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c
index ec1134c..208416e 100644
--- a/net/nfc/rawsock.c
+++ b/net/nfc/rawsock.c
@@ -54,11 +54,12 @@ static int rawsock_release(struct socket *sock)
 {
 	struct sock *sk = sock->sk;
 
-	pr_debug("sock=%p\n", sock);
-
-	sock_orphan(sk);
-	sock_put(sk);
+	pr_debug("sock=%p sk=%p\n", sock, sk);
 
+	if (sk) {
+		sock_orphan(sk);
+		sock_put(sk);
+	}
 	return 0;
 }
 

Re: [PATCH] net: nfc: fix panic in accept()

[Samuel Ortiz]

Hi Eric,

On Mon, Jun 25, 2012 at 05:53:32PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> Sasha Levin reported following panic :
I applied a similar patch, more consistent with the rest of the NFC socket
code, still with you as the author. See here:

http://git.kernel.org/?p=linux/kernel/git/sameo/nfc-3.0.git;a=commit;h=631c301f20558525a641fadffc0126affd3dc4a4

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] net: nfc: fix panic in accept()

[Sasha Levin]

Hi Samuel,

On Mon, Jun 25, 2012 at 7:15 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Eric,
>
> On Mon, Jun 25, 2012 at 05:53:32PM +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Sasha Levin reported following panic :
> I applied a similar patch, more consistent with the rest of the NFC socket
> code, still with you as the author. See here:
>
> http://git.kernel.org/?p=linux/kernel/git/sameo/nfc-3.0.git;a=commit;h=631c301f20558525a641fadffc0126affd3dc4a4

Could this tree be included in -next please?

Re: [PATCH] net: nfc: fix panic in accept()

[Samuel Ortiz]

Hi Sasha,

On Thu, Jun 28, 2012 at 02:11:38PM +0200, Sasha Levin wrote:
> Hi Samuel,
> 
> On Mon, Jun 25, 2012 at 7:15 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> > Hi Eric,
> >
> > On Mon, Jun 25, 2012 at 05:53:32PM +0200, Eric Dumazet wrote:
> >> From: Eric Dumazet <edumazet@google.com>
> >>
> >> Sasha Levin reported following panic :
> > I applied a similar patch, more consistent with the rest of the NFC socket
> > code, still with you as the author. See here:
> >
> > http://git.kernel.org/?p=linux/kernel/git/sameo/nfc-3.0.git;a=commit;h=631c301f20558525a641fadffc0126affd3dc4a4
> 
> Could this tree be included in -next please?
No, wireless-next is already included in -next. The above patch is making its
way upstream, it's in the wireless.git tree and should hit davem's net tree
soon.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] net: nfc: fix panic in accept()

[John W. Linville]

On Thu, Jun 28, 2012 at 02:56:12PM +0200, Samuel Ortiz wrote:
> Hi Sasha,
> 
> On Thu, Jun 28, 2012 at 02:11:38PM +0200, Sasha Levin wrote:
> > Hi Samuel,
> > 
> > On Mon, Jun 25, 2012 at 7:15 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> > > Hi Eric,
> > >
> > > On Mon, Jun 25, 2012 at 05:53:32PM +0200, Eric Dumazet wrote:
> > >> From: Eric Dumazet <edumazet@google.com>
> > >>
> > >> Sasha Levin reported following panic :
> > > I applied a similar patch, more consistent with the rest of the NFC socket
> > > code, still with you as the author. See here:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/sameo/nfc-3.0.git;a=commit;h=631c301f20558525a641fadffc0126affd3dc4a4
> > 
> > Could this tree be included in -next please?
> No, wireless-next is already included in -next. The above patch is making its
> way upstream, it's in the wireless.git tree and should hit davem's net tree
> soon.

FWIW, lots (or most?) of the bug fix trees get pulled into -next
as well.  Having the nfc tree go there makes sense to me.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.