linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* KASAN: use-after-free Read in locks_delete_block
@ 2018-11-12 20:34 syzbot
  2018-11-13 10:37 ` Jeff Layton
  2018-11-13 19:58 ` syzbot
  0 siblings, 2 replies; 13+ messages in thread
From: syzbot @ 2018-11-12 20:34 UTC (permalink / raw)
  To: bfields, jlayton, linux-fsdevel, linux-kernel, syzkaller-bugs, viro

Hello,

syzbot found the following crash on:

HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com

device loop0 blocksize: 4096
__find_get_block_slow() failed. block=1, b_blocknr=8
b_state=0x00000029, b_size=512
device loop0 blocksize: 4096
==================================================================
BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100  
lib/list_debug.c:51
Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461

CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+  
#110
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x244/0x39d lib/dump_stack.c:113
  print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
  __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
  __list_del_entry include/linux/list.h:117 [inline]
  list_del_init include/linux/list.h:159 [inline]
  __locks_delete_block fs/locks.c:683 [inline]
  locks_delete_block+0xce/0x3d0 fs/locks.c:716
  locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
  rw_verify_area+0x2f2/0x360 fs/read_write.c:386
  vfs_write+0x149/0x560 fs/read_write.c:544
  ksys_write+0x101/0x260 fs/read_write.c:598
  __do_sys_write fs/read_write.c:610 [inline]
  __se_sys_write fs/read_write.c:607 [inline]
  __x64_sys_write+0x73/0xb0 fs/read_write.c:607
  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff

The buggy address belongs to the page:
page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                              ^
  ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-12 20:34 KASAN: use-after-free Read in locks_delete_block syzbot
@ 2018-11-13 10:37 ` Jeff Layton
  2018-11-13 20:40   ` NeilBrown
  2018-11-13 19:58 ` syzbot
  1 sibling, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2018-11-13 10:37 UTC (permalink / raw)
  To: syzbot, bfields, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
  Cc: Neil Brown

On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
> dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
> 
> device loop0 blocksize: 4096
> __find_get_block_slow() failed. block=1, b_blocknr=8
> b_state=0x00000029, b_size=512
> device loop0 blocksize: 4096
> ==================================================================
> BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100  
> lib/list_debug.c:51
> Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
> 
> CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+  
> #110
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
> Google 01/01/2011
> Call Trace:
>   __dump_stack lib/dump_stack.c:77 [inline]
>   dump_stack+0x244/0x39d lib/dump_stack.c:113
>   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>   kasan_report_error mm/kasan/report.c:354 [inline]
>   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
>   __list_del_entry include/linux/list.h:117 [inline]
>   list_del_init include/linux/list.h:159 [inline]
>   __locks_delete_block fs/locks.c:683 [inline]
>   locks_delete_block+0xce/0x3d0 fs/locks.c:716
>   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
>   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
>   vfs_write+0x149/0x560 fs/read_write.c:544
>   ksys_write+0x101/0x260 fs/read_write.c:598
>   __do_sys_write fs/read_write.c:610 [inline]
>   __se_sys_write fs/read_write.c:607 [inline]
>   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
> RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
> RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
> R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
> 
> The buggy address belongs to the page:
> page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
>                                                               ^
>   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==================================================================
> 

Ouch, crash down in the mandatory locking code. This is with Neil's set
from last week. I haven't merged the series he sent the other day yet,
but they don't seem to be different in this regard.

Looks like the fl_blocked list might have had an entry on it that was
freed without being removed? locks_mandatory_area declares a file_lock
on the stack, but it seems to be initialized properly.

The one weird thing is that locks_mandatory_area sets FL_ACCESS and
FL_SLEEP, but I don't see anything wrong with that right offhand.

Neil, any thoughts?
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-12 20:34 KASAN: use-after-free Read in locks_delete_block syzbot
  2018-11-13 10:37 ` Jeff Layton
@ 2018-11-13 19:58 ` syzbot
  1 sibling, 0 replies; 13+ messages in thread
From: syzbot @ 2018-11-13 19:58 UTC (permalink / raw)
  To: bfields, jlayton, linux-fsdevel, linux-kernel, neilb,
	syzkaller-bugs, viro

syzbot has found a reproducer for the following crash on:

HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12fbd905400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10480d33400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100  
lib/list_debug.c:51
Read of size 8 at addr ffff8801b27c7c70 by task syz-executor0/6767

CPU: 1 PID: 6767 Comm: syz-executor0 Not tainted 4.20.0-rc1-next-20181109+  
#110
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x244/0x39d lib/dump_stack.c:113
  print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
  __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
  __list_del_entry include/linux/list.h:117 [inline]
  list_del_init include/linux/list.h:159 [inline]
  __locks_delete_block fs/locks.c:683 [inline]
  locks_delete_block+0xce/0x3d0 fs/locks.c:716
  locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
  locks_verify_truncate include/linux/fs.h:2361 [inline]
  do_sys_ftruncate+0x4b2/0x550 fs/open.c:190
  __do_sys_ftruncate fs/open.c:204 [inline]
  __se_sys_ftruncate fs/open.c:202 [inline]
  __x64_sys_ftruncate+0x59/0x80 fs/open.c:202
  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4319e97c78 EFLAGS: 00000246 ORIG_RAX: 000000000000004d
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457569
RDX: 0000000000000000 RSI: 0000000000000039 RDI: 0000000000000004
RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4319e986d4
R13: 00000000004bde51 R14: 00000000004cd048 R15: 00000000ffffffff

The buggy address belongs to the page:
page:ffffea0006c9f1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 ffffffff06c90101 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff8801b27c7b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ffff8801b27c7b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801b27c7c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                              ^
  ffff8801b27c7c80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ffff8801b27c7d00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-13 10:37 ` Jeff Layton
@ 2018-11-13 20:40   ` NeilBrown
  2018-11-14 10:36     ` Jeff Layton
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2018-11-13 20:40 UTC (permalink / raw)
  To: Jeff Layton, syzbot, bfields, linux-fsdevel, linux-kernel,
	syzkaller-bugs, viro
  Cc: Neil Brown

[-- Attachment #1: Type: text/plain, Size: 5577 bytes --]

On Tue, Nov 13 2018, Jeff Layton wrote:

> On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>> Hello,
>> 
>> syzbot found the following crash on:
>> 
>> HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
>> git tree:       linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
>> dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> 
>> Unfortunately, I don't have any reproducer for this crash yet.
>> 
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
>> 
>> device loop0 blocksize: 4096
>> __find_get_block_slow() failed. block=1, b_blocknr=8
>> b_state=0x00000029, b_size=512
>> device loop0 blocksize: 4096
>> ==================================================================
>> BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100  
>> lib/list_debug.c:51
>> Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
>> 
>> CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+  
>> #110
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
>> Google 01/01/2011
>> Call Trace:
>>   __dump_stack lib/dump_stack.c:77 [inline]
>>   dump_stack+0x244/0x39d lib/dump_stack.c:113
>>   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>>   kasan_report_error mm/kasan/report.c:354 [inline]
>>   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>>   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>>   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
>>   __list_del_entry include/linux/list.h:117 [inline]
>>   list_del_init include/linux/list.h:159 [inline]
>>   __locks_delete_block fs/locks.c:683 [inline]
>>   locks_delete_block+0xce/0x3d0 fs/locks.c:716
>>   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
>>   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
>>   vfs_write+0x149/0x560 fs/read_write.c:544
>>   ksys_write+0x101/0x260 fs/read_write.c:598
>>   __do_sys_write fs/read_write.c:610 [inline]
>>   __se_sys_write fs/read_write.c:607 [inline]
>>   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>>   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x457569
>> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
>> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
>> RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
>> RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
>> R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
>> 
>> The buggy address belongs to the page:
>> page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
>> flags: 0x2fffc0000000000()
>> raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
>> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
>> page dumped because: kasan: bad access detected
>> 
>> Memory state around the buggy address:
>>   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 
>>                                                               ^
>>   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> ==================================================================
>> 
>
> Ouch, crash down in the mandatory locking code. This is with Neil's set
> from last week. I haven't merged the series he sent the other day yet,
> but they don't seem to be different in this regard.
>
> Looks like the fl_blocked list might have had an entry on it that was
> freed without being removed? locks_mandatory_area declares a file_lock
> on the stack, but it seems to be initialized properly.
>
> The one weird thing is that locks_mandatory_area sets FL_ACCESS and
> FL_SLEEP, but I don't see anything wrong with that right offhand.
>
> Neil, any thoughts?

I'm not certain, but probably this:

From: NeilBrown <neilb@suse.com>
Date: Wed, 14 Nov 2018 07:38:05 +1100
Subject: [PATCH] fs/locks: always delete_block after waiting - mandatory locks

The patch
      fs/locks: always delete_block after waiting.
should have moved the locks_delete_block() call in
locks_mandatory_area() too.

This might fix the bug:
Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com

Signed-off-by: NeilBrown <neilb@suse.com>
---
 fs/locks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/locks.c b/fs/locks.c
index f456cd3d9d50..eb0c0b33fb7b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1436,9 +1436,9 @@ int locks_mandatory_area(struct inode *inode, struct file *filp, loff_t start,
 				continue;
 		}
 
-		locks_delete_block(&fl);
 		break;
 	}
+	locks_delete_block(&fl);
 
 	return error;
 }
-- 
2.14.0.rc0.dirty


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply related	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-13 20:40   ` NeilBrown
@ 2018-11-14 10:36     ` Jeff Layton
  2018-11-15 22:45       ` Dmitry Vyukov
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2018-11-14 10:36 UTC (permalink / raw)
  To: NeilBrown, syzbot, bfields, linux-fsdevel, linux-kernel,
	syzkaller-bugs, viro

On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
> On Tue, Nov 13 2018, Jeff Layton wrote:
> 
> > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following crash on:
> > > 
> > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
> > > git tree:       linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
> > > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> > > 
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > > 
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
> > > 
> > > device loop0 blocksize: 4096
> > > __find_get_block_slow() failed. block=1, b_blocknr=8
> > > b_state=0x00000029, b_size=512
> > > device loop0 blocksize: 4096
> > > ==================================================================
> > > BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100  
> > > lib/list_debug.c:51
> > > Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
> > > 
> > > CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+  
> > > #110
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
> > > Google 01/01/2011
> > > Call Trace:
> > >   __dump_stack lib/dump_stack.c:77 [inline]
> > >   dump_stack+0x244/0x39d lib/dump_stack.c:113
> > >   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> > >   kasan_report_error mm/kasan/report.c:354 [inline]
> > >   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> > >   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> > >   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
> > >   __list_del_entry include/linux/list.h:117 [inline]
> > >   list_del_init include/linux/list.h:159 [inline]
> > >   __locks_delete_block fs/locks.c:683 [inline]
> > >   locks_delete_block+0xce/0x3d0 fs/locks.c:716
> > >   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
> > >   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
> > >   vfs_write+0x149/0x560 fs/read_write.c:544
> > >   ksys_write+0x101/0x260 fs/read_write.c:598
> > >   __do_sys_write fs/read_write.c:610 [inline]
> > >   __se_sys_write fs/read_write.c:607 [inline]
> > >   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
> > >   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > RIP: 0033:0x457569
> > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
> > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
> > > RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
> > > RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
> > > R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
> > > 
> > > The buggy address belongs to the page:
> > > page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
> > > flags: 0x2fffc0000000000()
> > > raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
> > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> > > page dumped because: kasan: bad access detected
> > > 
> > > Memory state around the buggy address:
> > >   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > >   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > 
> > >                                                               ^
> > >   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > >   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > ==================================================================
> > > 
> > 
> > Ouch, crash down in the mandatory locking code. This is with Neil's set
> > from last week. I haven't merged the series he sent the other day yet,
> > but they don't seem to be different in this regard.
> > 
> > Looks like the fl_blocked list might have had an entry on it that was
> > freed without being removed? locks_mandatory_area declares a file_lock
> > on the stack, but it seems to be initialized properly.
> > 
> > The one weird thing is that locks_mandatory_area sets FL_ACCESS and
> > FL_SLEEP, but I don't see anything wrong with that right offhand.
> > 
> > Neil, any thoughts?
> 
> I'm not certain, but probably this:
> 
> From: NeilBrown <neilb@suse.com>
> Date: Wed, 14 Nov 2018 07:38:05 +1100
> Subject: [PATCH] fs/locks: always delete_block after waiting - mandatory locks
> 
> The patch
>       fs/locks: always delete_block after waiting.
> should have moved the locks_delete_block() call in
> locks_mandatory_area() too.
> 
> This might fix the bug:
> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
> 
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
>  fs/locks.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index f456cd3d9d50..eb0c0b33fb7b 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1436,9 +1436,9 @@ int locks_mandatory_area(struct inode *inode, struct file *filp, loff_t start,
>  				continue;
>  		}
>  
> -		locks_delete_block(&fl);
>  		break;
>  	}
> +	locks_delete_block(&fl);
>  
>  	return error;
>  }

That makes sense. I went ahead and squashed this patch into the earlier
one and pushed the result to my locks-next branch. linux-next should
pick it up soon.

Thanks!
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-14 10:36     ` Jeff Layton
@ 2018-11-15 22:45       ` Dmitry Vyukov
  2018-11-15 23:41         ` NeilBrown
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Vyukov @ 2018-11-15 22:45 UTC (permalink / raw)
  To: Jeff Layton
  Cc: NeilBrown, syzbot, Bruce Fields, linux-fsdevel, LKML,
	syzkaller-bugs, Al Viro

On Wed, Nov 14, 2018 at 2:36 AM, Jeff Layton <jlayton@kernel.org> wrote:
> On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
>> On Tue, Nov 13 2018, Jeff Layton wrote:
>>
>> > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>> > > Hello,
>> > >
>> > > syzbot found the following crash on:
>> > >
>> > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
>> > > git tree:       linux-next
>> > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
>> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
>> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
>> > > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> > >
>> > > Unfortunately, I don't have any reproducer for this crash yet.
>> > >
>> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > > Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Hi Neil,

Please include the Reported-by tag next time.

I see the linux-next patch is already update,
so let's tell syzbot that this is fixed here:

#syz fix: fs/locks: always delete_block after waiting.

If the bug is still open on syzbot dashboard:
https://syzkaller.appspot.com#upstream
syzbot will not report new bugs in these functions in future.

Thanks

>> > > device loop0 blocksize: 4096
>> > > __find_get_block_slow() failed. block=1, b_blocknr=8
>> > > b_state=0x00000029, b_size=512
>> > > device loop0 blocksize: 4096
>> > > ==================================================================
>> > > BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100
>> > > lib/list_debug.c:51
>> > > Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
>> > >
>> > > CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+
>> > > #110
>> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> > > Google 01/01/2011
>> > > Call Trace:
>> > >   __dump_stack lib/dump_stack.c:77 [inline]
>> > >   dump_stack+0x244/0x39d lib/dump_stack.c:113
>> > >   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>> > >   kasan_report_error mm/kasan/report.c:354 [inline]
>> > >   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>> > >   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>> > >   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
>> > >   __list_del_entry include/linux/list.h:117 [inline]
>> > >   list_del_init include/linux/list.h:159 [inline]
>> > >   __locks_delete_block fs/locks.c:683 [inline]
>> > >   locks_delete_block+0xce/0x3d0 fs/locks.c:716
>> > >   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
>> > >   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
>> > >   vfs_write+0x149/0x560 fs/read_write.c:544
>> > >   ksys_write+0x101/0x260 fs/read_write.c:598
>> > >   __do_sys_write fs/read_write.c:610 [inline]
>> > >   __se_sys_write fs/read_write.c:607 [inline]
>> > >   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>> > >   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> > >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> > > RIP: 0033:0x457569
>> > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>> > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> > > RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
>> > > RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
>> > > RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
>> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
>> > > R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
>> > >
>> > > The buggy address belongs to the page:
>> > > page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
>> > > flags: 0x2fffc0000000000()
>> > > raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
>> > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
>> > > page dumped because: kasan: bad access detected
>> > >
>> > > Memory state around the buggy address:
>> > >   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > >   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > > > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > >
>> > >                                                               ^
>> > >   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > >   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > > ==================================================================
>> > >
>> >
>> > Ouch, crash down in the mandatory locking code. This is with Neil's set
>> > from last week. I haven't merged the series he sent the other day yet,
>> > but they don't seem to be different in this regard.
>> >
>> > Looks like the fl_blocked list might have had an entry on it that was
>> > freed without being removed? locks_mandatory_area declares a file_lock
>> > on the stack, but it seems to be initialized properly.
>> >
>> > The one weird thing is that locks_mandatory_area sets FL_ACCESS and
>> > FL_SLEEP, but I don't see anything wrong with that right offhand.
>> >
>> > Neil, any thoughts?
>>
>> I'm not certain, but probably this:
>>
>> From: NeilBrown <neilb@suse.com>
>> Date: Wed, 14 Nov 2018 07:38:05 +1100
>> Subject: [PATCH] fs/locks: always delete_block after waiting - mandatory locks
>>
>> The patch
>>       fs/locks: always delete_block after waiting.
>> should have moved the locks_delete_block() call in
>> locks_mandatory_area() too.
>>
>> This might fix the bug:
>> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
>>
>> Signed-off-by: NeilBrown <neilb@suse.com>
>> ---
>>  fs/locks.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/locks.c b/fs/locks.c
>> index f456cd3d9d50..eb0c0b33fb7b 100644
>> --- a/fs/locks.c
>> +++ b/fs/locks.c
>> @@ -1436,9 +1436,9 @@ int locks_mandatory_area(struct inode *inode, struct file *filp, loff_t start,
>>                               continue;
>>               }
>>
>> -             locks_delete_block(&fl);
>>               break;
>>       }
>> +     locks_delete_block(&fl);
>>
>>       return error;
>>  }
>
> That makes sense. I went ahead and squashed this patch into the earlier
> one and pushed the result to my locks-next branch. linux-next should
> pick it up soon.
>
> Thanks!
> --
> Jeff Layton <jlayton@kernel.org>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/b49e02d54460c79c4e5472983f6b9390005881b8.camel%40kernel.org.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-15 22:45       ` Dmitry Vyukov
@ 2018-11-15 23:41         ` NeilBrown
  2018-11-16 20:37           ` Dmitry Vyukov
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2018-11-15 23:41 UTC (permalink / raw)
  To: Dmitry Vyukov, Jeff Layton
  Cc: syzbot, Bruce Fields, linux-fsdevel, LKML, syzkaller-bugs, Al Viro

[-- Attachment #1: Type: text/plain, Size: 7853 bytes --]

On Thu, Nov 15 2018, Dmitry Vyukov wrote:

> On Wed, Nov 14, 2018 at 2:36 AM, Jeff Layton <jlayton@kernel.org> wrote:
>> On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
>>> On Tue, Nov 13 2018, Jeff Layton wrote:
>>>
>>> > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>>> > > Hello,
>>> > >
>>> > > syzbot found the following crash on:
>>> > >
>>> > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
>>> > > git tree:       linux-next
>>> > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
>>> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
>>> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
>>> > > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>> > >
>>> > > Unfortunately, I don't have any reproducer for this crash yet.
>>> > >
>>> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> > > Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
> Hi Neil,
>
> Please include the Reported-by tag next time.

I did, as you can see below.

When the fix is merged into the patch that introduced the bug, do you
still want the Reported-by there, even though the bug and the fix are no
longer visible?  What if I were to completely rewrite the patch - do I
still need the Reported-by??

I'm certainly happy to give credit where due, but keeping a complete
history of past bugs in a single commit seems excessive.
Please help me to understand your needs.

>
> I see the linux-next patch is already update,
> so let's tell syzbot that this is fixed here:
>
> #syz fix: fs/locks: always delete_block after waiting.
>
> If the bug is still open on syzbot dashboard:
> https://syzkaller.appspot.com#upstream
> syzbot will not report new bugs in these functions in future.
>
> Thanks
>
>>> > > device loop0 blocksize: 4096
>>> > > __find_get_block_slow() failed. block=1, b_blocknr=8
>>> > > b_state=0x00000029, b_size=512
>>> > > device loop0 blocksize: 4096
>>> > > ==================================================================
>>> > > BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100
>>> > > lib/list_debug.c:51
>>> > > Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
>>> > >
>>> > > CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+
>>> > > #110
>>> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> > > Google 01/01/2011
>>> > > Call Trace:
>>> > >   __dump_stack lib/dump_stack.c:77 [inline]
>>> > >   dump_stack+0x244/0x39d lib/dump_stack.c:113
>>> > >   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>>> > >   kasan_report_error mm/kasan/report.c:354 [inline]
>>> > >   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>>> > >   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>>> > >   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
>>> > >   __list_del_entry include/linux/list.h:117 [inline]
>>> > >   list_del_init include/linux/list.h:159 [inline]
>>> > >   __locks_delete_block fs/locks.c:683 [inline]
>>> > >   locks_delete_block+0xce/0x3d0 fs/locks.c:716
>>> > >   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
>>> > >   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
>>> > >   vfs_write+0x149/0x560 fs/read_write.c:544
>>> > >   ksys_write+0x101/0x260 fs/read_write.c:598
>>> > >   __do_sys_write fs/read_write.c:610 [inline]
>>> > >   __se_sys_write fs/read_write.c:607 [inline]
>>> > >   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>>> > >   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>> > >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>> > > RIP: 0033:0x457569
>>> > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>>> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>>> > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>> > > RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
>>> > > RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
>>> > > RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
>>> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
>>> > > R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
>>> > >
>>> > > The buggy address belongs to the page:
>>> > > page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
>>> > > flags: 0x2fffc0000000000()
>>> > > raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
>>> > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
>>> > > page dumped because: kasan: bad access detected
>>> > >
>>> > > Memory state around the buggy address:
>>> > >   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> > >   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> > > > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> > >
>>> > >                                                               ^
>>> > >   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> > >   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> > > ==================================================================
>>> > >
>>> >
>>> > Ouch, crash down in the mandatory locking code. This is with Neil's set
>>> > from last week. I haven't merged the series he sent the other day yet,
>>> > but they don't seem to be different in this regard.
>>> >
>>> > Looks like the fl_blocked list might have had an entry on it that was
>>> > freed without being removed? locks_mandatory_area declares a file_lock
>>> > on the stack, but it seems to be initialized properly.
>>> >
>>> > The one weird thing is that locks_mandatory_area sets FL_ACCESS and
>>> > FL_SLEEP, but I don't see anything wrong with that right offhand.
>>> >
>>> > Neil, any thoughts?
>>>
>>> I'm not certain, but probably this:
>>>
>>> From: NeilBrown <neilb@suse.com>
>>> Date: Wed, 14 Nov 2018 07:38:05 +1100
>>> Subject: [PATCH] fs/locks: always delete_block after waiting - mandatory locks
>>>
>>> The patch
>>>       fs/locks: always delete_block after waiting.
>>> should have moved the locks_delete_block() call in
>>> locks_mandatory_area() too.
>>>
>>> This might fix the bug:
>>> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com

Here you see the Reported-by line that I included.

NeilBrown

>>>
>>> Signed-off-by: NeilBrown <neilb@suse.com>
>>> ---
>>>  fs/locks.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/locks.c b/fs/locks.c
>>> index f456cd3d9d50..eb0c0b33fb7b 100644
>>> --- a/fs/locks.c
>>> +++ b/fs/locks.c
>>> @@ -1436,9 +1436,9 @@ int locks_mandatory_area(struct inode *inode, struct file *filp, loff_t start,
>>>                               continue;
>>>               }
>>>
>>> -             locks_delete_block(&fl);
>>>               break;
>>>       }
>>> +     locks_delete_block(&fl);
>>>
>>>       return error;
>>>  }
>>
>> That makes sense. I went ahead and squashed this patch into the earlier
>> one and pushed the result to my locks-next branch. linux-next should
>> pick it up soon.
>>
>> Thanks!
>> --
>> Jeff Layton <jlayton@kernel.org>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/b49e02d54460c79c4e5472983f6b9390005881b8.camel%40kernel.org.
>> For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-15 23:41         ` NeilBrown
@ 2018-11-16 20:37           ` Dmitry Vyukov
  2018-11-17 13:33             ` Jeff Layton
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Vyukov @ 2018-11-16 20:37 UTC (permalink / raw)
  To: NeilBrown
  Cc: Jeff Layton, syzbot, Bruce Fields, linux-fsdevel, LKML,
	syzkaller-bugs, Al Viro

On Thu, Nov 15, 2018 at 3:41 PM, NeilBrown <neilb@suse.com> wrote:
> On Thu, Nov 15 2018, Dmitry Vyukov wrote:
>
>> On Wed, Nov 14, 2018 at 2:36 AM, Jeff Layton <jlayton@kernel.org> wrote:
>>> On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
>>>> On Tue, Nov 13 2018, Jeff Layton wrote:
>>>>
>>>> > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>>>> > > Hello,
>>>> > >
>>>> > > syzbot found the following crash on:
>>>> > >
>>>> > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
>>>> > > git tree:       linux-next
>>>> > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
>>>> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
>>>> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
>>>> > > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>>> > >
>>>> > > Unfortunately, I don't have any reproducer for this crash yet.
>>>> > >
>>>> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>> > > Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
>>
>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>>
>> Hi Neil,
>>
>> Please include the Reported-by tag next time.
>
> I did, as you can see below.
>
> When the fix is merged into the patch that introduced the bug, do you
> still want the Reported-by there, even though the bug and the fix are no
> longer visible?  What if I were to completely rewrite the patch - do I
> still need the Reported-by??
>
> I'm certainly happy to give credit where due, but keeping a complete
> history of past bugs in a single commit seems excessive.
> Please help me to understand your needs.

Here is the commit as I see it in linux-next:
https://gist.githubusercontent.com/dvyukov/ac1791c98d95618a48548cef8df84558/raw/a3f819cca2f0bb47db0c2e88d35d020accb069b5/gistfile1.txt
As far as I see it already includes the fix to locks_mandatory_area,
but does not include the tag. Maybe it was merged somehow incorrectly.

This is not so much about credit, but more about proper bug tracking.
But reports on mailing lists are periodically being lost, and then it
also may be hard to understand when a new crash is a new bug which
needs to be reported again or an old lost bug.
syzbot keeps track of all reported bugs and has a notion of
open/active reports that still need human attention:
https://syzkaller.appspot.com/#upstream
and fixed/closed reports that don't need human attention anymore.
The Reported-by tags are intercepted by syzbot and allows it to
understand when a bug is fixed and needs to be closed.
Keeping track of this is important for 2 reasons:
1. Closed/fixed bugs go away from the dashboard, so people don't go
over them again and again.
2. If a bug is closed, syzbot will report new similarly looking bugs
in future (otherwise it will just merge new crashes into the old bug,
because it thinks it's still the old bug happenning).

linux-next is somewhat special because commits are being amended, so a
commit can effectively fix itself. But one way or another syzbot needs
to know about fixes. Reported-by tags take care of all tracking.
Otherwise, a human needs to first notice that there is an already
fixed bug that is still considered open, find the fixing commit and
issue the "#syz fix" command as I did above. This is especially
problematic for linux-next as it changes and bisection does not work.
Here is more info on syzbot bug status tracking:
https://goo.gl/tpsmEJ#bug-status-tracking


>> I see the linux-next patch is already update,
>> so let's tell syzbot that this is fixed here:
>>
>> #syz fix: fs/locks: always delete_block after waiting.
>>
>> If the bug is still open on syzbot dashboard:
>> https://syzkaller.appspot.com#upstream
>> syzbot will not report new bugs in these functions in future.
>>
>> Thanks
>>
>>>> > > device loop0 blocksize: 4096
>>>> > > __find_get_block_slow() failed. block=1, b_blocknr=8
>>>> > > b_state=0x00000029, b_size=512
>>>> > > device loop0 blocksize: 4096
>>>> > > ==================================================================
>>>> > > BUG: KASAN: use-after-free in __list_del_entry_valid+0xf1/0x100
>>>> > > lib/list_debug.c:51
>>>> > > Read of size 8 at addr ffff88017eb47b70 by task syz-executor3/13461
>>>> > >
>>>> > > CPU: 0 PID: 13461 Comm: syz-executor3 Not tainted 4.20.0-rc1-next-20181109+
>>>> > > #110
>>>> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>> > > Google 01/01/2011
>>>> > > Call Trace:
>>>> > >   __dump_stack lib/dump_stack.c:77 [inline]
>>>> > >   dump_stack+0x244/0x39d lib/dump_stack.c:113
>>>> > >   print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
>>>> > >   kasan_report_error mm/kasan/report.c:354 [inline]
>>>> > >   kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
>>>> > >   __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>>>> > >   __list_del_entry_valid+0xf1/0x100 lib/list_debug.c:51
>>>> > >   __list_del_entry include/linux/list.h:117 [inline]
>>>> > >   list_del_init include/linux/list.h:159 [inline]
>>>> > >   __locks_delete_block fs/locks.c:683 [inline]
>>>> > >   locks_delete_block+0xce/0x3d0 fs/locks.c:716
>>>> > >   locks_mandatory_area+0x48b/0x6a0 fs/locks.c:1398
>>>> > >   rw_verify_area+0x2f2/0x360 fs/read_write.c:386
>>>> > >   vfs_write+0x149/0x560 fs/read_write.c:544
>>>> > >   ksys_write+0x101/0x260 fs/read_write.c:598
>>>> > >   __do_sys_write fs/read_write.c:610 [inline]
>>>> > >   __se_sys_write fs/read_write.c:607 [inline]
>>>> > >   __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>>>> > >   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>>> > >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>>> > > RIP: 0033:0x457569
>>>> > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>>>> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>>>> > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>>> > > RSP: 002b:00007ff2e8194c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
>>>> > > RDX: 0000000000000010 RSI: 0000000020000180 RDI: 0000000000000006
>>>> > > RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
>>>> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff2e81956d4
>>>> > > R13: 00000000004c571f R14: 00000000004d9360 R15: 00000000ffffffff
>>>> > >
>>>> > > The buggy address belongs to the page:
>>>> > > page:ffffea0005fad1c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
>>>> > > flags: 0x2fffc0000000000()
>>>> > > raw: 02fffc0000000000 0000000000000000 ffffea0005fad1c8 0000000000000000
>>>> > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
>>>> > > page dumped because: kasan: bad access detected
>>>> > >
>>>> > > Memory state around the buggy address:
>>>> > >   ffff88017eb47a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>> > >   ffff88017eb47a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>> > > > ffff88017eb47b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>> > >
>>>> > >                                                               ^
>>>> > >   ffff88017eb47b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>> > >   ffff88017eb47c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>> > > ==================================================================
>>>> > >
>>>> >
>>>> > Ouch, crash down in the mandatory locking code. This is with Neil's set
>>>> > from last week. I haven't merged the series he sent the other day yet,
>>>> > but they don't seem to be different in this regard.
>>>> >
>>>> > Looks like the fl_blocked list might have had an entry on it that was
>>>> > freed without being removed? locks_mandatory_area declares a file_lock
>>>> > on the stack, but it seems to be initialized properly.
>>>> >
>>>> > The one weird thing is that locks_mandatory_area sets FL_ACCESS and
>>>> > FL_SLEEP, but I don't see anything wrong with that right offhand.
>>>> >
>>>> > Neil, any thoughts?
>>>>
>>>> I'm not certain, but probably this:
>>>>
>>>> From: NeilBrown <neilb@suse.com>
>>>> Date: Wed, 14 Nov 2018 07:38:05 +1100
>>>> Subject: [PATCH] fs/locks: always delete_block after waiting - mandatory locks
>>>>
>>>> The patch
>>>>       fs/locks: always delete_block after waiting.
>>>> should have moved the locks_delete_block() call in
>>>> locks_mandatory_area() too.
>>>>
>>>> This might fix the bug:
>>>> Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
>
> Here you see the Reported-by line that I included.
>
> NeilBrown
>
>>>>
>>>> Signed-off-by: NeilBrown <neilb@suse.com>
>>>> ---
>>>>  fs/locks.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/locks.c b/fs/locks.c
>>>> index f456cd3d9d50..eb0c0b33fb7b 100644
>>>> --- a/fs/locks.c
>>>> +++ b/fs/locks.c
>>>> @@ -1436,9 +1436,9 @@ int locks_mandatory_area(struct inode *inode, struct file *filp, loff_t start,
>>>>                               continue;
>>>>               }
>>>>
>>>> -             locks_delete_block(&fl);
>>>>               break;
>>>>       }
>>>> +     locks_delete_block(&fl);
>>>>
>>>>       return error;
>>>>  }
>>>
>>> That makes sense. I went ahead and squashed this patch into the earlier
>>> one and pushed the result to my locks-next branch. linux-next should
>>> pick it up soon.
>>>
>>> Thanks!
>>> --
>>> Jeff Layton <jlayton@kernel.org>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/b49e02d54460c79c4e5472983f6b9390005881b8.camel%40kernel.org.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/87bm6pewnm.fsf%40notabene.neil.brown.name.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-16 20:37           ` Dmitry Vyukov
@ 2018-11-17 13:33             ` Jeff Layton
  2018-11-17 14:03               ` Bruce Fields
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2018-11-17 13:33 UTC (permalink / raw)
  To: Dmitry Vyukov, NeilBrown
  Cc: syzbot, Bruce Fields, linux-fsdevel, LKML, syzkaller-bugs, Al Viro

On Fri, 2018-11-16 at 12:37 -0800, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2018 at 3:41 PM, NeilBrown <neilb@suse.com> wrote:
> > On Thu, Nov 15 2018, Dmitry Vyukov wrote:
> > 
> > > On Wed, Nov 14, 2018 at 2:36 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > > > On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
> > > > > On Tue, Nov 13 2018, Jeff Layton wrote:
> > > > > 
> > > > > > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > syzbot found the following crash on:
> > > > > > > 
> > > > > > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
> > > > > > > git tree:       linux-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
> > > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
> > > > > > > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> > > > > > > 
> > > > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > > > > 
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
> > > 
> > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> > > 
> > > Hi Neil,
> > > 
> > > Please include the Reported-by tag next time.
> > 
> > I did, as you can see below.
> > 
> > When the fix is merged into the patch that introduced the bug, do you
> > still want the Reported-by there, even though the bug and the fix are no
> > longer visible?  What if I were to completely rewrite the patch - do I
> > still need the Reported-by??
> > 
> > I'm certainly happy to give credit where due, but keeping a complete
> > history of past bugs in a single commit seems excessive.
> > Please help me to understand your needs.
> 
> Here is the commit as I see it in linux-next:
> https://gist.githubusercontent.com/dvyukov/ac1791c98d95618a48548cef8df84558/raw/a3f819cca2f0bb47db0c2e88d35d020accb069b5/gistfile1.txt
> As far as I see it already includes the fix to locks_mandatory_area,
> but does not include the tag. Maybe it was merged somehow incorrectly.
>
> This is not so much about credit, but more about proper bug tracking.
> But reports on mailing lists are periodically being lost, and then it
> also may be hard to understand when a new crash is a new bug which
> needs to be reported again or an old lost bug.
> syzbot keeps track of all reported bugs and has a notion of
> open/active reports that still need human attention:
> https://syzkaller.appspot.com/#upstream
> and fixed/closed reports that don't need human attention anymore.
> The Reported-by tags are intercepted by syzbot and allows it to
> understand when a bug is fixed and needs to be closed.
> Keeping track of this is important for 2 reasons:
> 1. Closed/fixed bugs go away from the dashboard, so people don't go
> over them again and again.
> 2. If a bug is closed, syzbot will report new similarly looking bugs
> in future (otherwise it will just merge new crashes into the old bug,
> because it thinks it's still the old bug happenning).
> 
> linux-next is somewhat special because commits are being amended, so a
> commit can effectively fix itself. But one way or another syzbot needs
> to know about fixes. Reported-by tags take care of all tracking.
> Otherwise, a human needs to first notice that there is an already
> fixed bug that is still considered open, find the fixing commit and
> issue the "#syz fix" command as I did above. This is especially
> problematic for linux-next as it changes and bisection does not work.
> Here is more info on syzbot bug status tracking:
> https://goo.gl/tpsmEJ#bug-status-tracking
> 

Thanks for the explanation, Dmitry. I've added the tag to the patch in
my tree. It should show up in linux-next soon.

I still find it a little misleading to say that syzbot reported a bug
when it actually found a bug inside an earlier version of the patch, but
I'll just learn to get over it.

Thanks,
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-17 13:33             ` Jeff Layton
@ 2018-11-17 14:03               ` Bruce Fields
  2018-11-20  6:57                 ` Dmitry Vyukov
  0 siblings, 1 reply; 13+ messages in thread
From: Bruce Fields @ 2018-11-17 14:03 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Dmitry Vyukov, NeilBrown, syzbot, linux-fsdevel, LKML,
	syzkaller-bugs, Al Viro

On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
> Thanks for the explanation, Dmitry. I've added the tag to the patch in
> my tree. It should show up in linux-next soon.
> 
> I still find it a little misleading to say that syzbot reported a bug
> when it actually found a bug inside an earlier version of the patch, but
> I'll just learn to get over it.

The usual tag for someone that found a bug in an earlier version of a
patch would be Reviewed-by:.  Is there any reason we can't use that
here?  The "syzbot+..." email should be enough on its own, I can't see a
reason why their scripts would need to require a particular tag.  Or
maybe we could use Tested-by:, or some other tag made up for this case?

I do worry that someone who sees "Reported-by:..." might for example
mistakenly assume that it would help to backport that patch if they see
a similar-looking oops.

--b.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-17 14:03               ` Bruce Fields
@ 2018-11-20  6:57                 ` Dmitry Vyukov
  2018-11-20 11:08                   ` Jeff Layton
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Vyukov @ 2018-11-20  6:57 UTC (permalink / raw)
  To: Bruce Fields
  Cc: Jeff Layton, NeilBrown, syzbot, linux-fsdevel, LKML,
	syzkaller-bugs, Al Viro

On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields <bfields@fieldses.org> wrote:
> On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
>> Thanks for the explanation, Dmitry. I've added the tag to the patch in
>> my tree. It should show up in linux-next soon.
>>
>> I still find it a little misleading to say that syzbot reported a bug
>> when it actually found a bug inside an earlier version of the patch, but
>> I'll just learn to get over it.
>
> The usual tag for someone that found a bug in an earlier version of a
> patch would be Reviewed-by:.  Is there any reason we can't use that
> here?  The "syzbot+..." email should be enough on its own, I can't see a
> reason why their scripts would need to require a particular tag.  Or
> maybe we could use Tested-by:, or some other tag made up for this case?
>
> I do worry that someone who sees "Reported-by:..." might for example
> mistakenly assume that it would help to backport that patch if they see
> a similar-looking oops.

I see. It may also be picked by scripts that detects patches that need
to be backported to stable because of the "Reported-by: syzbot" tag.
This is somewhat unfortunate.

There is no problem parsing another tag on syzbot side. Does Tested-by
look good to you? If it found a bug in the patch and then it was
fixed, Tested-by looks reasonable. And we also detect
Reported-and-tested-by already because that's what syzbot suggests
after it tested a proposed fix for a bug.

I am somewhat concerned how to spread this information across all
kernel developers. There is effectively no way to do this. We can't
expect people to read docs, they generally don't. I guess I just
document this at "See https://goo.gl/tpsmEJ for more information" and
then we can point other people there if/when this concern pops up
again.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-20  6:57                 ` Dmitry Vyukov
@ 2018-11-20 11:08                   ` Jeff Layton
  2018-11-20 13:23                     ` Dmitry Vyukov
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2018-11-20 11:08 UTC (permalink / raw)
  To: Dmitry Vyukov, Bruce Fields
  Cc: NeilBrown, syzbot, linux-fsdevel, LKML, syzkaller-bugs, Al Viro

On Tue, 2018-11-20 at 07:57 +0100, Dmitry Vyukov wrote:
> On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields <bfields@fieldses.org> wrote:
> > On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
> > > Thanks for the explanation, Dmitry. I've added the tag to the patch in
> > > my tree. It should show up in linux-next soon.
> > > 
> > > I still find it a little misleading to say that syzbot reported a bug
> > > when it actually found a bug inside an earlier version of the patch, but
> > > I'll just learn to get over it.
> > 
> > The usual tag for someone that found a bug in an earlier version of a
> > patch would be Reviewed-by:.  Is there any reason we can't use that
> > here?  The "syzbot+..." email should be enough on its own, I can't see a
> > reason why their scripts would need to require a particular tag.  Or
> > maybe we could use Tested-by:, or some other tag made up for this case?
> > 
> > I do worry that someone who sees "Reported-by:..." might for example
> > mistakenly assume that it would help to backport that patch if they see
> > a similar-looking oops.
> 
> I see. It may also be picked by scripts that detects patches that need
> to be backported to stable because of the "Reported-by: syzbot" tag.
> This is somewhat unfortunate.
> 
> There is no problem parsing another tag on syzbot side. Does Tested-by
> look good to you? If it found a bug in the patch and then it was
> fixed, Tested-by looks reasonable. And we also detect
> Reported-and-tested-by already because that's what syzbot suggests
> after it tested a proposed fix for a bug.
> 
> I am somewhat concerned how to spread this information across all
> kernel developers. There is effectively no way to do this. We can't
> expect people to read docs, they generally don't. I guess I just
> document this at "See https://goo.gl/tpsmEJ for more information" and
> then we can point other people there if/when this concern pops up
> again.

Tested-by sounds like it might be a reasonable fit. I'll change the
patch in my tree to read that way.

Thanks,
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: KASAN: use-after-free Read in locks_delete_block
  2018-11-20 11:08                   ` Jeff Layton
@ 2018-11-20 13:23                     ` Dmitry Vyukov
  0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-11-20 13:23 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Bruce Fields, NeilBrown, syzbot, linux-fsdevel, LKML,
	syzkaller-bugs, Al Viro

On Tue, Nov 20, 2018 at 12:08 PM, Jeff Layton <jlayton@kernel.org> wrote:
> On Tue, 2018-11-20 at 07:57 +0100, Dmitry Vyukov wrote:
>> On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields <bfields@fieldses.org> wrote:
>> > On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
>> > > Thanks for the explanation, Dmitry. I've added the tag to the patch in
>> > > my tree. It should show up in linux-next soon.
>> > >
>> > > I still find it a little misleading to say that syzbot reported a bug
>> > > when it actually found a bug inside an earlier version of the patch, but
>> > > I'll just learn to get over it.
>> >
>> > The usual tag for someone that found a bug in an earlier version of a
>> > patch would be Reviewed-by:.  Is there any reason we can't use that
>> > here?  The "syzbot+..." email should be enough on its own, I can't see a
>> > reason why their scripts would need to require a particular tag.  Or
>> > maybe we could use Tested-by:, or some other tag made up for this case?
>> >
>> > I do worry that someone who sees "Reported-by:..." might for example
>> > mistakenly assume that it would help to backport that patch if they see
>> > a similar-looking oops.
>>
>> I see. It may also be picked by scripts that detects patches that need
>> to be backported to stable because of the "Reported-by: syzbot" tag.
>> This is somewhat unfortunate.
>>
>> There is no problem parsing another tag on syzbot side. Does Tested-by
>> look good to you? If it found a bug in the patch and then it was
>> fixed, Tested-by looks reasonable. And we also detect
>> Reported-and-tested-by already because that's what syzbot suggests
>> after it tested a proposed fix for a bug.
>>
>> I am somewhat concerned how to spread this information across all
>> kernel developers. There is effectively no way to do this. We can't
>> expect people to read docs, they generally don't. I guess I just
>> document this at "See https://goo.gl/tpsmEJ for more information" and
>> then we can point other people there if/when this concern pops up
>> again.
>
> Tested-by sounds like it might be a reasonable fit. I'll change the
> patch in my tree to read that way.

Turns out this already works (we did not check exact tag, just search
for the right email with a hash). So I added a test for Tested-by tag
and extended the docs:
https://github.com/google/syzkaller/commit/9aca6b5240809308d9078a0a0f0707512c5b0220

^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-11-20 13:23 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-12 20:34 KASAN: use-after-free Read in locks_delete_block syzbot
2018-11-13 10:37 ` Jeff Layton
2018-11-13 20:40   ` NeilBrown
2018-11-14 10:36     ` Jeff Layton
2018-11-15 22:45       ` Dmitry Vyukov
2018-11-15 23:41         ` NeilBrown
2018-11-16 20:37           ` Dmitry Vyukov
2018-11-17 13:33             ` Jeff Layton
2018-11-17 14:03               ` Bruce Fields
2018-11-20  6:57                 ` Dmitry Vyukov
2018-11-20 11:08                   ` Jeff Layton
2018-11-20 13:23                     ` Dmitry Vyukov
2018-11-13 19:58 ` syzbot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).