* KASAN: use-after-free Read in ucma_close (2)
@ 2020-09-10 14:09 syzbot
[not found] ` <20200911041640.20652-1-hdanton@sina.com>
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: syzbot @ 2020-09-10 14:09 UTC (permalink / raw)
To: dledford, jgg, leon, linux-kernel, linux-rdma, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1002ea2d900000
kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
dashboard link: https://syzkaller.appspot.com/bug?extid=cc6fc752b3819e082d0c
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1600e053900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in ucma_close+0x2a4/0x310 drivers/infiniband/core/ucma.c:1839
Read of size 4 at addr ffff8880a748b538 by task syz-executor.0/7260
CPU: 0 PID: 7260 Comm: syz-executor.0 Not tainted 5.9.0-rc4-syzkaller #0
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+0x198/0x1fd lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
ucma_close+0x2a4/0x310 drivers/infiniband/core/ucma.c:1839
__fput+0x285/0x920 fs/file_table.c:281
task_work_run+0xdd/0x190 kernel/task_work.c:141
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_user_mode_loop kernel/entry/common.c:163 [inline]
exit_to_user_mode_prepare+0x1e1/0x200 kernel/entry/common.c:190
syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:265
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x416f01
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007ffd5e376f90 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000416f01
RDX: 0000000000000001 RSI: 0000000000000080 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 00007ffd5e377080 R11: 0000000000000293 R12: 0000000001190ed0
R13: 000000000007fa65 R14: ffffffffffffffff R15: 000000000118cfec
Allocated by task 7261:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
kmem_cache_alloc_trace+0x174/0x2c0 mm/slab.c:3550
kmalloc include/linux/slab.h:554 [inline]
kzalloc include/linux/slab.h:666 [inline]
ucma_alloc_ctx+0x4b/0x480 drivers/infiniband/core/ucma.c:212
ucma_create_id+0x11b/0x590 drivers/infiniband/core/ucma.c:502
ucma_write+0x288/0x350 drivers/infiniband/core/ucma.c:1768
vfs_write+0x2b0/0x730 fs/read_write.c:576
ksys_write+0x1ee/0x250 fs/read_write.c:631
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 7261:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
__kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
__cache_free mm/slab.c:3418 [inline]
kfree+0x10e/0x2b0 mm/slab.c:3756
ucma_free_ctx+0x7f6/0xae0 drivers/infiniband/core/ucma.c:600
ucma_destroy_id+0x30c/0x460 drivers/infiniband/core/ucma.c:644
ucma_write+0x288/0x350 drivers/infiniband/core/ucma.c:1768
vfs_write+0x2b0/0x730 fs/read_write.c:576
ksys_write+0x1ee/0x250 fs/read_write.c:631
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a748b400
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 312 bytes inside of
512-byte region [ffff8880a748b400, ffff8880a748b600)
The buggy address belongs to the page:
page:000000002b52c09c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xa748b
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002416c48 ffff8880aa041750 ffff8880aa040600
raw: 0000000000000000 ffff8880a748b000 0000000100000004 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a748b400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880a748b480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880a748b500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880a748b580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880a748b600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
[not found] ` <20200911041640.20652-1-hdanton@sina.com>
@ 2020-09-11 11:57 ` Jason Gunthorpe
[not found] ` <20200911152017.18644-1-hdanton@sina.com>
1 sibling, 0 replies; 8+ messages in thread
From: Jason Gunthorpe @ 2020-09-11 11:57 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, dledford, leon, linux-kernel, linux-rdma, syzkaller-bugs
On Fri, Sep 11, 2020 at 12:16:40PM +0800, Hillf Danton wrote:
> Detect race destroying ctx in order to avoid UAF.
>
> +++ b/drivers/infiniband/core/ucma.c
> @@ -625,6 +625,10 @@ static ssize_t ucma_destroy_id(struct uc
> return PTR_ERR(ctx);
>
> mutex_lock(&ctx->file->mut);
> + if (ctx->destroying == 1) {
> + mutex_unlock(&ctx->file->mut);
> + return -ENXIO;
> + }
> ctx->destroying = 1;
> mutex_unlock(&ctx->file->mut);
>
> @@ -1826,6 +1830,8 @@ static int ucma_close(struct inode *inod
>
> mutex_lock(&file->mut);
> list_for_each_entry_safe(ctx, tmp, &file->ctx_list, list) {
> + if (ctx->destroying == 1)
> + continue;
> ctx->destroying = 1;
> mutex_unlock(&file->mut);
>
ucma_destroy_id() is called from write() and ucma_close is release(),
so there is no way these can race?
Jason
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
2020-09-10 14:09 KASAN: use-after-free Read in ucma_close (2) syzbot
[not found] ` <20200911041640.20652-1-hdanton@sina.com>
@ 2020-09-11 12:02 ` Jason Gunthorpe
2020-09-11 15:49 ` syzbot
2020-09-11 18:19 ` Jason Gunthorpe
2 siblings, 1 reply; 8+ messages in thread
From: Jason Gunthorpe @ 2020-09-11 12:02 UTC (permalink / raw)
To: syzbot; +Cc: dledford, leon, linux-kernel, linux-rdma, syzkaller-bugs
On Thu, Sep 10, 2020 at 07:09:24AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1002ea2d900000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
> dashboard link: https://syzkaller.appspot.com/bug?extid=cc6fc752b3819e082d0c
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1600e053900000
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git 308571debccd7004acf02ea1b7163a96ad772292
Jason
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
2020-09-11 12:02 ` Jason Gunthorpe
@ 2020-09-11 15:49 ` syzbot
0 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2020-09-11 15:49 UTC (permalink / raw)
To: dledford, jgg, leon, linux-kernel, linux-rdma, syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in __destroy_id
==================================================================
BUG: KASAN: use-after-free in __destroy_id+0x9f5/0xc60 drivers/infiniband/core/ucma.c:620
Read of size 4 at addr ffff88808e210128 by task syz-executor.2/11716
CPU: 1 PID: 11716 Comm: syz-executor.2 Not tainted 5.9.0-rc1-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
__destroy_id+0x9f5/0xc60 drivers/infiniband/core/ucma.c:620
ucma_destroy_id+0x172/0x240 drivers/infiniband/core/ucma.c:654
ucma_write+0x288/0x350 drivers/infiniband/core/ucma.c:1784
vfs_write+0x2b0/0x730 fs/read_write.c:576
ksys_write+0x1ee/0x250 fs/read_write.c:631
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45d5b9
Code: 5d b4 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 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff28d19dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000038340 RCX: 000000000045d5b9
RDX: 0000000000000018 RSI: 00000000200000c0 RDI: 0000000000000005
RBP: 000000000118cf80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cf4c
R13: 00007ffcebc2643f R14: 00007ff28d19e9c0 R15: 000000000118cf4c
Allocated by task 11716:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
kmem_cache_alloc_trace+0x16e/0x2c0 mm/slab.c:3550
kmalloc include/linux/slab.h:554 [inline]
kzalloc include/linux/slab.h:666 [inline]
ucma_alloc_ctx+0x41/0x330 drivers/infiniband/core/ucma.c:211
ucma_create_id+0x10f/0x410 drivers/infiniband/core/ucma.c:497
ucma_write+0x288/0x350 drivers/infiniband/core/ucma.c:1784
vfs_write+0x2b0/0x730 fs/read_write.c:576
ksys_write+0x1ee/0x250 fs/read_write.c:631
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 11715:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
__kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
__cache_free mm/slab.c:3418 [inline]
kfree+0x103/0x2c0 mm/slab.c:3756
ucma_free_ctx drivers/infiniband/core/ucma.c:599 [inline]
__destroy_id+0x8a2/0xc60 drivers/infiniband/core/ucma.c:628
ucma_close+0xe1/0x190 drivers/infiniband/core/ucma.c:1849
__fput+0x285/0x920 fs/file_table.c:281
task_work_run+0xdd/0x190 kernel/task_work.c:141
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_user_mode_loop kernel/entry/common.c:139 [inline]
exit_to_user_mode_prepare+0x195/0x1c0 kernel/entry/common.c:166
syscall_exit_to_user_mode+0x59/0x2b0 kernel/entry/common.c:241
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff88808e210000
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 296 bytes inside of
512-byte region [ffff88808e210000, ffff88808e210200)
The buggy address belongs to the page:
page:000000007a3e4a58 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88808e210c00 pfn:0x8e210
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002404fc8 ffffea00028aa008 ffff8880aa040600
raw: ffff88808e210c00 ffff88808e210000 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88808e210000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808e210080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88808e210100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88808e210180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808e210200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Tested on:
commit: 308571de RDMA/ucma: Do not use file->mut to lock destroying
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
console output: https://syzkaller.appspot.com/x/log.txt?x=112f7cdd900000
kernel config: https://syzkaller.appspot.com/x/.config?x=3d400a47d1416652
dashboard link: https://syzkaller.appspot.com/bug?extid=cc6fc752b3819e082d0c
compiler: gcc (GCC) 10.1.0-syz 20200507
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
[not found] ` <20200911152017.18644-1-hdanton@sina.com>
@ 2020-09-11 17:01 ` Jason Gunthorpe
[not found] ` <20200912013514.18380-1-hdanton@sina.com>
1 sibling, 0 replies; 8+ messages in thread
From: Jason Gunthorpe @ 2020-09-11 17:01 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, dledford, leon, linux-kernel, linux-rdma, syzkaller-bugs
On Fri, Sep 11, 2020 at 11:20:17PM +0800, Hillf Danton wrote:
>
> On Fri, 11 Sep 2020 08:57:50 -0300 Jason Gunthorpe wrote:
> > On Fri, Sep 11, 2020 at 12:16:40PM +0800, Hillf Danton wrote:
> > > Detect race destroying ctx in order to avoid UAF.
> > >
> > > +++ b/drivers/infiniband/core/ucma.c
> > > @@ -625,6 +625,10 @@ static ssize_t ucma_destroy_id(struct uc
> > > return PTR_ERR(ctx);
> > >
> > > mutex_lock(&ctx->file->mut);
> > > + if (ctx->destroying == 1) {
> > > + mutex_unlock(&ctx->file->mut);
> > > + return -ENXIO;
> > > + }
> > > ctx->destroying = 1;
> > > mutex_unlock(&ctx->file->mut);
> > >
> > > @@ -1826,6 +1830,8 @@ static int ucma_close(struct inode *inod
> > >
> > > mutex_lock(&file->mut);
> > > list_for_each_entry_safe(ctx, tmp, &file->ctx_list, list) {
> > > + if (ctx->destroying == 1)
> > > + continue;
> > > ctx->destroying = 1;
> > > mutex_unlock(&file->mut);
> > >
> >
> > ucma_destroy_id() is called from write() and ucma_close is release(),
> > so there is no way these can race?
>
> Sound good but what's reported is uaf in the close path, which is
> impossible without another thread releasing the ctx a step ahead
> the closer.
> Can we call it a race if that's true?
Migrate is the cause, very tricky:
CPU0 CPU1
ucma_destroy_id()
ucma_migrate_id()
ucma_get_ctx()
xa_lock()
_ucma_find_context()
xa_erase()
xa_lock()
ctx->file = new_file
list_move()
xa_unlock()
ucma_put_ctx
ucma_close()
_destroy_id()
_destroy_id()
wait_for_completion()
// boom
ie the destrory_id() on the initial FD captures the ctx right before
migrate moves it, then the new FD closes calling destroy while the
other destroy is still running.
Sigh, I will rewrite migrate too..
Jason
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
2020-09-10 14:09 KASAN: use-after-free Read in ucma_close (2) syzbot
[not found] ` <20200911041640.20652-1-hdanton@sina.com>
2020-09-11 12:02 ` Jason Gunthorpe
@ 2020-09-11 18:19 ` Jason Gunthorpe
2020-09-11 20:53 ` syzbot
2 siblings, 1 reply; 8+ messages in thread
From: Jason Gunthorpe @ 2020-09-11 18:19 UTC (permalink / raw)
To: syzbot; +Cc: dledford, leon, linux-kernel, linux-rdma, syzkaller-bugs
On Thu, Sep 10, 2020 at 07:09:24AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1002ea2d900000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
> dashboard link: https://syzkaller.appspot.com/bug?extid=cc6fc752b3819e082d0c
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1600e053900000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com
#syz test: https://github.com/jgunthorpe/linux ucma_migrate_fix
Jason
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
2020-09-11 18:19 ` Jason Gunthorpe
@ 2020-09-11 20:53 ` syzbot
0 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2020-09-11 20:53 UTC (permalink / raw)
To: dledford, jgg, leon, linux-kernel, linux-rdma, syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com
Tested on:
commit: 7c003f9a RDMA/ucma: Rework ucma_migrate_id() to avoid race..
git tree: https://github.com/jgunthorpe/linux ucma_migrate_fix
kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299
dashboard link: https://syzkaller.appspot.com/bug?extid=cc6fc752b3819e082d0c
compiler: gcc (GCC) 10.1.0-syz 20200507
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN: use-after-free Read in ucma_close (2)
[not found] ` <20200912013514.18380-1-hdanton@sina.com>
@ 2020-09-14 15:01 ` Jason Gunthorpe
0 siblings, 0 replies; 8+ messages in thread
From: Jason Gunthorpe @ 2020-09-14 15:01 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, dledford, leon, linux-kernel, linux-rdma, syzkaller-bugs
On Sat, Sep 12, 2020 at 09:35:14AM +0800, Hillf Danton wrote:
> > Migrate is the cause, very tricky:
> >
> > CPU0 CPU1
> > ucma_destroy_id()
> > ucma_migrate_id()
> > ucma_get_ctx()
> > xa_lock()
> > _ucma_find_context()
> > xa_erase()
> > xa_lock()
> > ctx->file = new_file
> > list_move()
> > xa_unlock()
> > ucma_put_ctx
> > ucma_close()
> > _destroy_id()
> >
> > _destroy_id()
> > wait_for_completion()
> > // boom
> >
> >
> > ie the destrory_id() on the initial FD captures the ctx right before
> > migrate moves it, then the new FD closes calling destroy while the
> > other destroy is still running.
>
> More trouble now understanding that the ctx is reported to be freed
> in the write path, while if I dont misread the chart above, you're
> trying to pull another closer after migrate into the race.
migrate moves the ctx between two struct file's, so the race is to be
destroying on fir the first struct file, move to the second struct
file, then close the second struct file.
Now close and destroy_id can race directly, which shouldn't be
allowed.
Jason
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-09-14 15:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-10 14:09 KASAN: use-after-free Read in ucma_close (2) syzbot
[not found] ` <20200911041640.20652-1-hdanton@sina.com>
2020-09-11 11:57 ` Jason Gunthorpe
[not found] ` <20200911152017.18644-1-hdanton@sina.com>
2020-09-11 17:01 ` Jason Gunthorpe
[not found] ` <20200912013514.18380-1-hdanton@sina.com>
2020-09-14 15:01 ` Jason Gunthorpe
2020-09-11 12:02 ` Jason Gunthorpe
2020-09-11 15:49 ` syzbot
2020-09-11 18:19 ` Jason Gunthorpe
2020-09-11 20:53 ` syzbot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.