Re: net: BUG in unix_notinflight

2017-03-10 Thread Cong Wang
On Tue, Mar 7, 2017 at 2:23 PM, Nikolay Borisov
 wrote:
>
>>>
>>>
>>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
>>>
>>> [ cut here ]
>>> kernel BUG at net/unix/garbage.c:149!
>>> invalid opcode:  [#1] SMP KASAN
>>> Dumping ftrace buffer:
>>>(ftrace buffer empty)
>>> Modules linked in:
>>> CPU: 0 PID: 1806 Comm: syz-executor7 Not tainted 4.10.0-next-20170303+ #6
>>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>>> BIOS Google 01/01/2011
>>> task: 880121c64740 task.stack: 88012c9e8000
>>> RIP: 0010:unix_notinflight+0x417/0x5d0 net/unix/garbage.c:149
>>> RSP: 0018:88012c9ef0f8 EFLAGS: 00010297
>>> RAX: 880121c64740 RBX: 11002593de23 RCX: 8801c490c628
>>> RDX:  RSI: 11002593de27 RDI: 8557e504
>>> RBP: 88012c9ef220 R08: 0001 R09: 
>>> R10: dc00 R11: ed002593de55 R12: 8801c490c0c0
>>> R13: 88012c9ef1f8 R14: 85101620 R15: dc00
>>> FS:  013d3940() GS:8801dbe0() knlGS:
>>> CS:  0010 DS:  ES:  CR0: 80050033
>>> CR2: 01fd8cd8 CR3: 0001cce69000 CR4: 001426f0
>>> Call Trace:
>>>  unix_detach_fds.isra.23+0xfa/0x170 net/unix/af_unix.c:1490
>>>  unix_destruct_scm+0xf4/0x200 net/unix/af_unix.c:1499
>>
>> The problem here is there is no lock protecting concurrent unix_detach_fds()
>> even though unix_notinflight() is already serialized, if we call
>> unix_notinflight()
>> twice on the same file pointer, we trigger this bug...
>>
>> I don't know what is the right lock here to serialize it.
>>
>
>
> I reported something similar a while ago
> https://lists.gt.net/linux/kernel/2534612
>
> And Miklos Szeredi then produced the following patch :
>
> https://patchwork.kernel.org/patch/9305121/
>
> However, this was never applied. I wonder if the patch makes sense?

I doubt it is the same case. According to Miklos' description,
the case he tried to fix is MSG_PEEK, but Dmitry's test case does not
set it... They are different problems probably.


Re: net: BUG in unix_notinflight

2017-03-07 Thread Cong Wang
On Tue, Mar 7, 2017 at 12:37 AM, Dmitry Vyukov  wrote:
> On Mon, Mar 6, 2017 at 11:34 PM, Cong Wang  wrote:
>> The problem here is there is no lock protecting concurrent unix_detach_fds()
>> even though unix_notinflight() is already serialized, if we call
>> unix_notinflight()
>> twice on the same file pointer, we trigger this bug...
>>
>> I don't know what is the right lock here to serialize it.
>
>
> What exactly here needs to be protected?
>
> 1484 static void unix_detach_fds(struct scm_cookie *scm, struct sk_buff *skb)
> 1485 {
> 1486 int i;
> 1487
> 1488 scm->fp = UNIXCB(skb).fp;
> 1489 UNIXCB(skb).fp = NULL;
> 1490
> 1491 for (i = scm->fp->count-1; i >= 0; i--)
> 1492 unix_notinflight(scm->fp->user, scm->fp->fp[i]);
> 1493 }
>
> Whole unix_notinflight happens under global unix_gc_lock.
>
> Is it that 2 threads call unix_detach_fds for the same skb, and then
> call unix_notinflight for the same fd twice?

Not the same skb, but their UNIXCB(skb).fp points to the same place,
therefore we call unix_notinflight() twice on the same fp->user and
fp->fp[i], although we have refcounting but still able to trigger this
warning.


Re: net: BUG in unix_notinflight

2017-03-07 Thread Willy Tarreau
On Wed, Mar 08, 2017 at 12:23:56AM +0200, Nikolay Borisov wrote:
> 
> >>
> >>
> >> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
> >>
> >> [ cut here ]
> >> kernel BUG at net/unix/garbage.c:149!
> >> invalid opcode:  [#1] SMP KASAN
> >> Dumping ftrace buffer:
> >>(ftrace buffer empty)
> >> Modules linked in:
> >> CPU: 0 PID: 1806 Comm: syz-executor7 Not tainted 4.10.0-next-20170303+ #6
> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> BIOS Google 01/01/2011
> >> task: 880121c64740 task.stack: 88012c9e8000
> >> RIP: 0010:unix_notinflight+0x417/0x5d0 net/unix/garbage.c:149
> >> RSP: 0018:88012c9ef0f8 EFLAGS: 00010297
> >> RAX: 880121c64740 RBX: 11002593de23 RCX: 8801c490c628
> >> RDX:  RSI: 11002593de27 RDI: 8557e504
> >> RBP: 88012c9ef220 R08: 0001 R09: 
> >> R10: dc00 R11: ed002593de55 R12: 8801c490c0c0
> >> R13: 88012c9ef1f8 R14: 85101620 R15: dc00
> >> FS:  013d3940() GS:8801dbe0() 
> >> knlGS:
> >> CS:  0010 DS:  ES:  CR0: 80050033
> >> CR2: 01fd8cd8 CR3: 0001cce69000 CR4: 001426f0
> >> Call Trace:
> >>  unix_detach_fds.isra.23+0xfa/0x170 net/unix/af_unix.c:1490
> >>  unix_destruct_scm+0xf4/0x200 net/unix/af_unix.c:1499
> > 
> > The problem here is there is no lock protecting concurrent unix_detach_fds()
> > even though unix_notinflight() is already serialized, if we call
> > unix_notinflight()
> > twice on the same file pointer, we trigger this bug...
> > 
> > I don't know what is the right lock here to serialize it.
> > 
> 
> 
> I reported something similar a while ago
> https://lists.gt.net/linux/kernel/2534612
> 
> And Miklos Szeredi then produced the following patch :
> 
> https://patchwork.kernel.org/patch/9305121/
> 
> However, this was never applied. I wonder if the patch makes sense?

I don't know but there's a hint at the bottom of the thread with
Davem's response to which there was no followup :

  "Why would I apply a patch that's an RFC, doesn't have a proper commit
   message, lacks a proper signoff, and also lacks ACK's and feedback
   from other knowledgable developers?"

So at least this point makes sense, maybe the patch is fine but was
not sufficiently reviewed or acked ? Maybe it was proposed as an RFC
to start a discussion and never went to the final status of a patch
waiting for being applied ?

Willy



Re: net: BUG in unix_notinflight

2017-03-07 Thread Nikolay Borisov

>>
>>
>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
>>
>> [ cut here ]
>> kernel BUG at net/unix/garbage.c:149!
>> invalid opcode:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 1806 Comm: syz-executor7 Not tainted 4.10.0-next-20170303+ #6
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> task: 880121c64740 task.stack: 88012c9e8000
>> RIP: 0010:unix_notinflight+0x417/0x5d0 net/unix/garbage.c:149
>> RSP: 0018:88012c9ef0f8 EFLAGS: 00010297
>> RAX: 880121c64740 RBX: 11002593de23 RCX: 8801c490c628
>> RDX:  RSI: 11002593de27 RDI: 8557e504
>> RBP: 88012c9ef220 R08: 0001 R09: 
>> R10: dc00 R11: ed002593de55 R12: 8801c490c0c0
>> R13: 88012c9ef1f8 R14: 85101620 R15: dc00
>> FS:  013d3940() GS:8801dbe0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 01fd8cd8 CR3: 0001cce69000 CR4: 001426f0
>> Call Trace:
>>  unix_detach_fds.isra.23+0xfa/0x170 net/unix/af_unix.c:1490
>>  unix_destruct_scm+0xf4/0x200 net/unix/af_unix.c:1499
> 
> The problem here is there is no lock protecting concurrent unix_detach_fds()
> even though unix_notinflight() is already serialized, if we call
> unix_notinflight()
> twice on the same file pointer, we trigger this bug...
> 
> I don't know what is the right lock here to serialize it.
> 


I reported something similar a while ago
https://lists.gt.net/linux/kernel/2534612

And Miklos Szeredi then produced the following patch :

https://patchwork.kernel.org/patch/9305121/

However, this was never applied. I wonder if the patch makes sense?


Re: net: BUG in unix_notinflight

2017-03-07 Thread Dmitry Vyukov
On Mon, Mar 6, 2017 at 11:34 PM, Cong Wang  wrote:
> On Mon, Mar 6, 2017 at 2:40 AM, Dmitry Vyukov  wrote:
>> Now with a nice single-threaded C reproducer!
>
> Excellent...
>
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #define _GNU_SOURCE
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> void test()
>> {
>>   long r[54];
>>   memset(r, -1, sizeof(r));
>>   syscall(__NR_mmap, 0x2000ul, 0xfff000ul, 0x3ul, 0x32ul, -1, 0);
>>   r[1] = syscall(__NR_socketpair, 0x1ul, 0x5ul, 0x0ul, 0x20521ff8ul);
>>   r[2] = *(uint32_t*)0x20521ff8;
>>   r[3] = *(uint32_t*)0x20521ffc;
>>   r[5] = syscall(__NR_open, "/dev/net/tun", 0x20ul);
>>   r[6] = syscall(__NR_socketpair, 0x1ul, 0x5ul, 0x0ul,
>>  0x20d85000ul, 0, 0, 0, 0, 0);
>>   r[7] = *(uint32_t*)0x20d85000;
>>   (*(uint64_t*)0x2fc8 = (uint64_t)0x2000);
>>   (*(uint32_t*)0x2fd0 = (uint32_t)0xa);
>>   (*(uint64_t*)0x2fd8 = (uint64_t)0x2005d000);
>>   (*(uint64_t*)0x2fe0 = (uint64_t)0x8);
>>   (*(uint64_t*)0x2fe8 = (uint64_t)0x2ff0);
>>   (*(uint64_t*)0x2ff0 = (uint64_t)0x1);
>>   (*(uint32_t*)0x2ff8 = (uint32_t)0x0);
>>   (*(uint16_t*)0x2000 = (uint16_t)0x1);
>>   memcpy((void*)0x2002, "\x2e\x2f\x66\x69\x6c\x65\x30\x00", 8);
>>   (*(uint64_t*)0x2005d000 = (uint64_t)0x20784f06);
>>   (*(uint64_t*)0x2005d008 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d010 = (uint64_t)0x209a5f78);
>>   (*(uint64_t*)0x2005d018 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d020 = (uint64_t)0x20ec3ffc);
>>   (*(uint64_t*)0x2005d028 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d030 = (uint64_t)0x2057e000);
>>   (*(uint64_t*)0x2005d038 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d040 = (uint64_t)0x200c9f9d);
>>   (*(uint64_t*)0x2005d048 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d050 = (uint64_t)0x20331000);
>>   (*(uint64_t*)0x2005d058 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d060 = (uint64_t)0x206a1f7b);
>>   (*(uint64_t*)0x2005d068 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2005d070 = (uint64_t)0x20e7f000);
>>   (*(uint64_t*)0x2005d078 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2ff0 = (uint64_t)0x18);
>>   (*(uint32_t*)0x2ff8 = (uint32_t)0x1);
>>   (*(uint32_t*)0x2ffc = (uint32_t)0x1);
>>   (*(uint32_t*)0x20001000 = r[5]);
>>   (*(uint32_t*)0x20001004 = r[7]);
>>   syscall(__NR_sendmsg, r[7], 0x2fc8ul, 0x0ul);
>>   (*(uint64_t*)0x2fc8 = (uint64_t)0x2000);
>>   (*(uint32_t*)0x2fd0 = (uint32_t)0x8);
>>   (*(uint64_t*)0x2fd8 = (uint64_t)0x20026000);
>>   (*(uint64_t*)0x2fe0 = (uint64_t)0x0);
>>   (*(uint64_t*)0x2fe8 = (uint64_t)0x2ff0);
>>   (*(uint64_t*)0x2ff0 = (uint64_t)0x1);
>>   (*(uint32_t*)0x2ff8 = (uint32_t)0x0);
>>   (*(uint16_t*)0x2000 = (uint16_t)0x0);
>>   (*(uint8_t*)0x2002 = (uint8_t)0x0);
>>   (*(uint32_t*)0x2004 = (uint32_t)0x4e20);
>>   (*(uint64_t*)0x2ff0 = (uint64_t)0x18);
>>   (*(uint32_t*)0x2ff8 = (uint32_t)0x1);
>>   (*(uint32_t*)0x2ffc = (uint32_t)0x1);
>>   (*(uint32_t*)0x20001000 = r[2]);
>>   syscall(__NR_sendmsg, r[3], 0x2fc8ul, 0x0ul);
>> }
>>
>> int main()
>> {
>>   int i, pid, status;
>>   for (i = 0; i < 4; i++) {
>> if (fork() == 0) {
>>   for (;;) {
>> pid = fork();
>> if (pid == 0) {
>>   test();
>>   exit(0);
>> }
>> while (waitpid(pid, , __WALL) != pid) {}
>>   }
>> }
>>   }
>>   sleep(100);
>>   return 0;
>> }
>>
>>
>>
>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
>>
>> [ cut here ]
>> kernel BUG at net/unix/garbage.c:149!
>> invalid opcode:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 1806 Comm: syz-executor7 Not tainted 4.10.0-next-20170303+ #6
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> task: 880121c64740 task.stack: 88012c9e8000
>> RIP: 0010:unix_notinflight+0x417/0x5d0 net/unix/garbage.c:149
>> RSP: 0018:88012c9ef0f8 EFLAGS: 00010297
>> RAX: 880121c64740 RBX: 11002593de23 RCX: 8801c490c628
>> RDX:  RSI: 11002593de27 RDI: 8557e504
>> RBP: 88012c9ef220 R08: 0001 R09: 
>> R10: dc00 R11: ed002593de55 R12: 8801c490c0c0
>> R13: 88012c9ef1f8 R14: 85101620 R15: dc00
>> FS:  013d3940() GS:8801dbe0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 01fd8cd8 CR3: 0001cce69000 CR4: 001426f0
>> Call Trace:
>>  unix_detach_fds.isra.23+0xfa/0x170 net/unix/af_unix.c:1490
>>  unix_destruct_scm+0xf4/0x200 net/unix/af_unix.c:1499
>
> The problem here is there is no lock protecting concurrent unix_detach_fds()
> even though unix_notinflight() is already serialized, if we 

Re: net: BUG in unix_notinflight

2017-03-06 Thread Cong Wang
On Mon, Mar 6, 2017 at 2:40 AM, Dmitry Vyukov  wrote:
> Now with a nice single-threaded C reproducer!

Excellent...

>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> void test()
> {
>   long r[54];
>   memset(r, -1, sizeof(r));
>   syscall(__NR_mmap, 0x2000ul, 0xfff000ul, 0x3ul, 0x32ul, -1, 0);
>   r[1] = syscall(__NR_socketpair, 0x1ul, 0x5ul, 0x0ul, 0x20521ff8ul);
>   r[2] = *(uint32_t*)0x20521ff8;
>   r[3] = *(uint32_t*)0x20521ffc;
>   r[5] = syscall(__NR_open, "/dev/net/tun", 0x20ul);
>   r[6] = syscall(__NR_socketpair, 0x1ul, 0x5ul, 0x0ul,
>  0x20d85000ul, 0, 0, 0, 0, 0);
>   r[7] = *(uint32_t*)0x20d85000;
>   (*(uint64_t*)0x2fc8 = (uint64_t)0x2000);
>   (*(uint32_t*)0x2fd0 = (uint32_t)0xa);
>   (*(uint64_t*)0x2fd8 = (uint64_t)0x2005d000);
>   (*(uint64_t*)0x2fe0 = (uint64_t)0x8);
>   (*(uint64_t*)0x2fe8 = (uint64_t)0x2ff0);
>   (*(uint64_t*)0x2ff0 = (uint64_t)0x1);
>   (*(uint32_t*)0x2ff8 = (uint32_t)0x0);
>   (*(uint16_t*)0x2000 = (uint16_t)0x1);
>   memcpy((void*)0x2002, "\x2e\x2f\x66\x69\x6c\x65\x30\x00", 8);
>   (*(uint64_t*)0x2005d000 = (uint64_t)0x20784f06);
>   (*(uint64_t*)0x2005d008 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d010 = (uint64_t)0x209a5f78);
>   (*(uint64_t*)0x2005d018 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d020 = (uint64_t)0x20ec3ffc);
>   (*(uint64_t*)0x2005d028 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d030 = (uint64_t)0x2057e000);
>   (*(uint64_t*)0x2005d038 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d040 = (uint64_t)0x200c9f9d);
>   (*(uint64_t*)0x2005d048 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d050 = (uint64_t)0x20331000);
>   (*(uint64_t*)0x2005d058 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d060 = (uint64_t)0x206a1f7b);
>   (*(uint64_t*)0x2005d068 = (uint64_t)0x0);
>   (*(uint64_t*)0x2005d070 = (uint64_t)0x20e7f000);
>   (*(uint64_t*)0x2005d078 = (uint64_t)0x0);
>   (*(uint64_t*)0x2ff0 = (uint64_t)0x18);
>   (*(uint32_t*)0x2ff8 = (uint32_t)0x1);
>   (*(uint32_t*)0x2ffc = (uint32_t)0x1);
>   (*(uint32_t*)0x20001000 = r[5]);
>   (*(uint32_t*)0x20001004 = r[7]);
>   syscall(__NR_sendmsg, r[7], 0x2fc8ul, 0x0ul);
>   (*(uint64_t*)0x2fc8 = (uint64_t)0x2000);
>   (*(uint32_t*)0x2fd0 = (uint32_t)0x8);
>   (*(uint64_t*)0x2fd8 = (uint64_t)0x20026000);
>   (*(uint64_t*)0x2fe0 = (uint64_t)0x0);
>   (*(uint64_t*)0x2fe8 = (uint64_t)0x2ff0);
>   (*(uint64_t*)0x2ff0 = (uint64_t)0x1);
>   (*(uint32_t*)0x2ff8 = (uint32_t)0x0);
>   (*(uint16_t*)0x2000 = (uint16_t)0x0);
>   (*(uint8_t*)0x2002 = (uint8_t)0x0);
>   (*(uint32_t*)0x2004 = (uint32_t)0x4e20);
>   (*(uint64_t*)0x2ff0 = (uint64_t)0x18);
>   (*(uint32_t*)0x2ff8 = (uint32_t)0x1);
>   (*(uint32_t*)0x2ffc = (uint32_t)0x1);
>   (*(uint32_t*)0x20001000 = r[2]);
>   syscall(__NR_sendmsg, r[3], 0x2fc8ul, 0x0ul);
> }
>
> int main()
> {
>   int i, pid, status;
>   for (i = 0; i < 4; i++) {
> if (fork() == 0) {
>   for (;;) {
> pid = fork();
> if (pid == 0) {
>   test();
>   exit(0);
> }
> while (waitpid(pid, , __WALL) != pid) {}
>   }
> }
>   }
>   sleep(100);
>   return 0;
> }
>
>
>
> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
>
> [ cut here ]
> kernel BUG at net/unix/garbage.c:149!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 1806 Comm: syz-executor7 Not tainted 4.10.0-next-20170303+ #6
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> task: 880121c64740 task.stack: 88012c9e8000
> RIP: 0010:unix_notinflight+0x417/0x5d0 net/unix/garbage.c:149
> RSP: 0018:88012c9ef0f8 EFLAGS: 00010297
> RAX: 880121c64740 RBX: 11002593de23 RCX: 8801c490c628
> RDX:  RSI: 11002593de27 RDI: 8557e504
> RBP: 88012c9ef220 R08: 0001 R09: 
> R10: dc00 R11: ed002593de55 R12: 8801c490c0c0
> R13: 88012c9ef1f8 R14: 85101620 R15: dc00
> FS:  013d3940() GS:8801dbe0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01fd8cd8 CR3: 0001cce69000 CR4: 001426f0
> Call Trace:
>  unix_detach_fds.isra.23+0xfa/0x170 net/unix/af_unix.c:1490
>  unix_destruct_scm+0xf4/0x200 net/unix/af_unix.c:1499

The problem here is there is no lock protecting concurrent unix_detach_fds()
even though unix_notinflight() is already serialized, if we call
unix_notinflight()
twice on the same file pointer, we trigger this bug...

I don't know what is the right lock here to serialize it.


Re: net: BUG in unix_notinflight

2017-03-06 Thread Dmitry Vyukov
On Sat, Nov 26, 2016 at 7:05 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I am hitting the following BUG while running syzkaller fuzzer:
>
> kernel BUG at net/unix/garbage.c:149!
> invalid opcode:  [#1] SMP DEBUG_PAGEALLOC KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 23491 Comm: syz-executor Not tainted 4.9.0-rc5+ #41
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> task: 8801c16b06c0 task.stack: 8801c2928000
> RIP: 0010:[]  []
> unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
> RSP: 0018:8801c292ea40  EFLAGS: 00010297
> RAX: 8801c16b06c0 RBX: 110038525d4a RCX: dc00
> RDX:  RSI: 110038525d4e RDI: 8a6e9d84
> RBP: 8801c292eb18 R08:  R09: 
> R10: cdca594876e035a1 R11: 0005 R12: 110038525d4e
> R13: 899156e0 R14: 8801c292eaf0 R15: 88018b7cd780
> FS:  7f10420fa700() GS:8801d980() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2000a000 CR3: 0001c2ecc000 CR4: 001406f0
> DR0:  DR1: 0400 DR2: 
> DR3:  DR6: 0ff0 DR7: 0600
> Stack:
>  dc00 88019f036970 41b58ab3 894c5120
>  8717e840 8801c16b06c0 88018b7cdcf0 894c51e2
>  81576d50   1100
> Call Trace:
>  [] unix_detach_fds.isra.19+0xff/0x170 
> net/unix/af_unix.c:1487
>  [] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
>  [] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
>  [] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
>  [] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
>  [] kfree_skb+0x184/0x570 net/core/skbuff.c:705
>  [] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
>  [] unix_release+0x49/0x90 net/unix/af_unix.c:836
>  [] sock_release+0x92/0x1f0 net/socket.c:570
>  [] sock_close+0x1b/0x20 net/socket.c:1017
>  [] __fput+0x34e/0x910 fs/file_table.c:208
>  [] fput+0x1a/0x20 fs/file_table.c:244
>  [] task_work_run+0x1a0/0x280 kernel/task_work.c:116
>  [< inline >] exit_task_work include/linux/task_work.h:21
>  [] do_exit+0x183a/0x2640 kernel/exit.c:828
>  [] do_group_exit+0x14e/0x420 kernel/exit.c:931
>  [] get_signal+0x663/0x1880 kernel/signal.c:2307
>  [] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
>  [] exit_to_usermode_loop+0x1ea/0x2d0
> arch/x86/entry/common.c:156
>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>  [] syscall_return_slowpath+0x4d3/0x570
> arch/x86/entry/common.c:259
>  [] entry_SYSCALL_64_fastpath+0xc4/0xc6
> Code: df 49 89 87 70 05 00 00 41 c6 04 14 f8 48 89 f9 48 c1 e9 03 80
> 3c 11 00 75 64 49 89 87 78 05 00 00 e9 65 ff ff ff e8 ac 94 56 fa <0f>
> 0b 48 89 d7 48 89 95 30 ff ff ff e8 bb 22 87 fa 48 8b 95 30
> RIP  [] unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
>  RSP 
> ---[ end trace 4cbbd52674b68dab ]---
>
>
> On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
> Unfortunately this is not reproducible outside of syzkaller.
> But easily reproducible with syzkaller. If you need to reproduce it,
> follow instructions described here:
> https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
> With the following as the program:
>
> mmap(&(0x7f00/0xdd5000)=nil, (0xdd5000), 0x3, 0x32,
> 0x, 0x0)
> socketpair$unix(0x1, 0x5, 0x0, 

net: BUG in unix_notinflight

2016-11-26 Thread Dmitry Vyukov
Hello,

I am hitting the following BUG while running syzkaller fuzzer:

kernel BUG at net/unix/garbage.c:149!
invalid opcode:  [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 23491 Comm: syz-executor Not tainted 4.9.0-rc5+ #41
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
task: 8801c16b06c0 task.stack: 8801c2928000
RIP: 0010:[]  []
unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
RSP: 0018:8801c292ea40  EFLAGS: 00010297
RAX: 8801c16b06c0 RBX: 110038525d4a RCX: dc00
RDX:  RSI: 110038525d4e RDI: 8a6e9d84
RBP: 8801c292eb18 R08:  R09: 
R10: cdca594876e035a1 R11: 0005 R12: 110038525d4e
R13: 899156e0 R14: 8801c292eaf0 R15: 88018b7cd780
FS:  7f10420fa700() GS:8801d980() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2000a000 CR3: 0001c2ecc000 CR4: 001406f0
DR0:  DR1: 0400 DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Stack:
 dc00 88019f036970 41b58ab3 894c5120
 8717e840 8801c16b06c0 88018b7cdcf0 894c51e2
 81576d50   1100
Call Trace:
 [] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
 [] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
 [] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
 [] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
 [] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
 [] kfree_skb+0x184/0x570 net/core/skbuff.c:705
 [] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
 [] unix_release+0x49/0x90 net/unix/af_unix.c:836
 [] sock_release+0x92/0x1f0 net/socket.c:570
 [] sock_close+0x1b/0x20 net/socket.c:1017
 [] __fput+0x34e/0x910 fs/file_table.c:208
 [] fput+0x1a/0x20 fs/file_table.c:244
 [] task_work_run+0x1a0/0x280 kernel/task_work.c:116
 [< inline >] exit_task_work include/linux/task_work.h:21
 [] do_exit+0x183a/0x2640 kernel/exit.c:828
 [] do_group_exit+0x14e/0x420 kernel/exit.c:931
 [] get_signal+0x663/0x1880 kernel/signal.c:2307
 [] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
 [] exit_to_usermode_loop+0x1ea/0x2d0
arch/x86/entry/common.c:156
 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [] syscall_return_slowpath+0x4d3/0x570
arch/x86/entry/common.c:259
 [] entry_SYSCALL_64_fastpath+0xc4/0xc6
Code: df 49 89 87 70 05 00 00 41 c6 04 14 f8 48 89 f9 48 c1 e9 03 80
3c 11 00 75 64 49 89 87 78 05 00 00 e9 65 ff ff ff e8 ac 94 56 fa <0f>
0b 48 89 d7 48 89 95 30 ff ff ff e8 bb 22 87 fa 48 8b 95 30
RIP  [] unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
 RSP 
---[ end trace 4cbbd52674b68dab ]---


On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
Unfortunately this is not reproducible outside of syzkaller.
But easily reproducible with syzkaller. If you need to reproduce it,
follow instructions described here:
https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
With the following as the program:

mmap(&(0x7f00/0xdd5000)=nil, (0xdd5000), 0x3, 0x32,
0x, 0x0)
socketpair$unix(0x1, 0x5, 0x0,