KASAN: use-after-free Read in generic_perform_write

29 views
Skip to first unread message

syzbot

unread,
Jul 19, 2018, 2:01:02 PM7/19/18
to ak...@linux-foundation.org, ja...@suse.cz, jla...@redhat.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, syzkall...@googlegroups.com, wi...@infradead.org
Hello,

syzbot found the following crash on:

HEAD commit: 1c34981993da Add linux-next specific files for 20180719
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16e6ac44400000
kernel config: https://syzkaller.appspot.com/x/.config?x=7002497517b09aec
dashboard link: https://syzkaller.appspot.com/bug?extid=b173e77096a8ba815511
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+b173e7...@syzkaller.appspotmail.com

IPVS: length: 141 != 24
XFS (loop5): Invalid superblock magic number
==================================================================
BUG: KASAN: use-after-free in memcpy include/linux/string.h:345 [inline]
BUG: KASAN: use-after-free in iov_iter_copy_from_user_atomic+0xb8d/0xfa0
lib/iov_iter.c:916
Read of size 21 at addr ffff880190103660 by task kworker/0:3/4927

CPU: 0 PID: 4927 Comm: kworker/0:3 Not tainted 4.18.0-rc5-next-20180719+ #11
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events p9_write_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x23/0x50 mm/kasan/kasan.c:302
memcpy include/linux/string.h:345 [inline]
iov_iter_copy_from_user_atomic+0xb8d/0xfa0 lib/iov_iter.c:916
generic_perform_write+0x469/0x6c0 mm/filemap.c:3058
__generic_file_write_iter+0x26e/0x630 mm/filemap.c:3175
ext4_file_write_iter+0x390/0x1450 fs/ext4/file.c:266
call_write_iter include/linux/fs.h:1826 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6af/0x9d0 fs/read_write.c:487
vfs_write+0x1fc/0x560 fs/read_write.c:549
kernel_write+0xab/0x120 fs/read_write.c:526
p9_fd_write net/9p/trans_fd.c:427 [inline]
p9_write_work+0x6f1/0xd50 net/9p/trans_fd.c:476
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

Allocated by task 13072:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc+0x14e/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:518 [inline]
p9_fcall_alloc+0x1e/0x90 net/9p/client.c:237
p9_tag_alloc net/9p/client.c:266 [inline]
p9_client_prepare_req.part.8+0x107/0xa00 net/9p/client.c:640
p9_client_prepare_req net/9p/client.c:675 [inline]
p9_client_rpc+0x242/0x1330 net/9p/client.c:675
p9_client_version net/9p/client.c:890 [inline]
p9_client_create+0xca4/0x1537 net/9p/client.c:974
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
legacy_get_tree+0x131/0x460 fs/fs_context.c:674
vfs_get_tree+0x1cb/0x5c0 fs/super.c:1743
do_new_mount fs/namespace.c:2603 [inline]
do_mount+0x6f2/0x1e20 fs/namespace.c:2927
ksys_mount+0x12d/0x140 fs/namespace.c:3143
__do_sys_mount fs/namespace.c:3157 [inline]
__se_sys_mount fs/namespace.c:3154 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3154
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 13072:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
p9_free_req+0xb5/0x120 net/9p/client.c:338
p9_client_rpc+0xa8e/0x1330 net/9p/client.c:739
p9_client_version net/9p/client.c:890 [inline]
p9_client_create+0xca4/0x1537 net/9p/client.c:974
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
legacy_get_tree+0x131/0x460 fs/fs_context.c:674
vfs_get_tree+0x1cb/0x5c0 fs/super.c:1743
do_new_mount fs/namespace.c:2603 [inline]
do_mount+0x6f2/0x1e20 fs/namespace.c:2927
ksys_mount+0x12d/0x140 fs/namespace.c:3143
__do_sys_mount fs/namespace.c:3157 [inline]
__se_sys_mount fs/namespace.c:3154 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3154
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff880190103640
which belongs to the cache kmalloc-16384 of size 16384
The buggy address is located 32 bytes inside of
16384-byte region [ffff880190103640, ffff880190107640)
The buggy address belongs to the page:
page:ffffea0006404000 count:1 mapcount:0 mapping:ffff8801da802200 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 ffffea000643b808 ffffea0006452c08 ffff8801da802200
raw: 0000000000000000 ffff880190103640 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff880190103500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff880190103580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff880190103600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff880190103680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880190103700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
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 syzk...@googlegroups.com.

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

Andrew Morton

unread,
Jul 19, 2018, 8:07:20 PM7/19/18
to syzbot, ja...@suse.cz, jla...@redhat.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, syzkall...@googlegroups.com, wi...@infradead.org, v9fs-de...@lists.sourceforge.net
On Thu, 19 Jul 2018 11:01:01 -0700 syzbot <syzbot+b173e7...@syzkaller.appspotmail.com> wrote:

> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1c34981993da Add linux-next specific files for 20180719
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16e6ac44400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7002497517b09aec
> dashboard link: https://syzkaller.appspot.com/bug?extid=b173e77096a8ba815511
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.

Thanks. I cc'ed v9fs-developer, optimistically. That list manager is
weird :(

I'm suspecting v9fs. Does that fs attempt to write to the fs from a
kmalloced buffer?

Full report below...

Dominique Martinet

unread,
Jul 19, 2018, 8:27:21 PM7/19/18
to Andrew Morton, syzbot, ja...@suse.cz, jla...@redhat.com, syzkall...@googlegroups.com, linux-...@vger.kernel.org, wi...@infradead.org, linu...@kvack.org, v9fs-de...@lists.sourceforge.net, mgo...@techsingularity.net
Andrew Morton wrote on Thu, Jul 19, 2018:
> On Thu, 19 Jul 2018 11:01:01 -0700 syzbot <syzbot+b173e7...@syzkaller.appspotmail.com> wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 1c34981993da Add linux-next specific files for 20180719
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16e6ac44400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=7002497517b09aec
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b173e77096a8ba815511
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
>
> Thanks. I cc'ed v9fs-developer, optimistically. That list manager is
> weird :(

I agree that list is weird, does anyone know the reason v9fs-developer
is not a vger.k.o list? Or a reason not to change? It's still not too
late...

> I'm suspecting v9fs. Does that fs attempt to write to the fs from a
> kmalloced buffer?

Difficult to say without any idea of what syzkaller tried doing, but it
looks like it hook'd up a fd opened to a local ext4 file into a trans_fd
mount; so sending a packet to the "server" would trigger a local write
instead.
The reason it's freed too early probably is that the reply came from a
read before the write happened; this is going to be tricky to fix as
that write is 100% asynchronous without any feedback right now (the
design assumes that the write has to have finished by the time reply
came), but if we want to protect ourselves from rogue servers we'll have
to think about something.

I'll write it down to not forget, thanks for the cc.

--
Dominique Martinet

Matthew Wilcox

unread,
Jul 19, 2018, 9:25:42 PM7/19/18
to Dominique Martinet, Andrew Morton, syzbot, ja...@suse.cz, jla...@redhat.com, syzkall...@googlegroups.com, linux-...@vger.kernel.org, linu...@kvack.org, v9fs-de...@lists.sourceforge.net, mgo...@techsingularity.net
On Fri, Jul 20, 2018 at 02:27:05AM +0200, Dominique Martinet wrote:
> Andrew Morton wrote on Thu, Jul 19, 2018:
> > On Thu, 19 Jul 2018 11:01:01 -0700 syzbot <syzbot+b173e7...@syzkaller.appspotmail.com> wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: 1c34981993da Add linux-next specific files for 20180719
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16e6ac44400000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=7002497517b09aec
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=b173e77096a8ba815511
> > > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
>
> > I'm suspecting v9fs. Does that fs attempt to write to the fs from a
> > kmalloced buffer?
>
> Difficult to say without any idea of what syzkaller tried doing, but it
> looks like it hook'd up a fd opened to a local ext4 file into a trans_fd
> mount; so sending a packet to the "server" would trigger a local write
> instead.
> The reason it's freed too early probably is that the reply came from a
> read before the write happened; this is going to be tricky to fix as
> that write is 100% asynchronous without any feedback right now (the
> design assumes that the write has to have finished by the time reply
> came), but if we want to protect ourselves from rogue servers we'll have
> to think about something.
>
> I'll write it down to not forget, thanks for the cc.

I suspect this got unmasked by my changes; before it would allocate
buffers and just leave them around. Now it'll free them, which means we
get to see this reuse (rather than having the buffer reused and getting
corrupt data written).

Not that I'm volunteering to fix this problem ;-)

syzbot

unread,
Jul 29, 2018, 7:18:04 PM7/29/18
to a...@linux.intel.com, ak...@linux-foundation.org, asma...@codewreck.org, ja...@suse.cz, jla...@redhat.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, syzkall...@googlegroups.com, v9fs-de...@lists.sourceforge.net, wi...@infradead.org
syzbot has found a reproducer for the following crash on:

HEAD commit: d1e0b8e0cb7a Add linux-next specific files for 20180725
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10eff978400000
kernel config: https://syzkaller.appspot.com/x/.config?x=eef3552c897e4d33
dashboard link: https://syzkaller.appspot.com/bug?extid=b173e77096a8ba815511
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=171d9578400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=132d14b4400000

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

RDX: 0000000000000030 RSI: 0000000020011fd2 RDI: 0000000000000004
RBP: 00000000006dbc40 R08: 00000000006dbc40 R09: 0000000000000000
R10: 00007fc1cd74ccf0 R11: 0000000000000246 R12: 00000000006dbc4c
R13: 00007fffabd5ea5f R14: 00007fc1cd74d9c0 R15: 00000000006dbd4c
==================================================================
BUG: KASAN: use-after-free in memcpy include/linux/string.h:345 [inline]
BUG: KASAN: use-after-free in iov_iter_copy_from_user_atomic+0xb8d/0xfa0
lib/iov_iter.c:916
Read of size 21 at addr ffff8801ad780d60 by task kworker/0:1/13

CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 4.18.0-rc6-next-20180725+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events p9_write_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x23/0x50 mm/kasan/kasan.c:302
memcpy include/linux/string.h:345 [inline]
iov_iter_copy_from_user_atomic+0xb8d/0xfa0 lib/iov_iter.c:916
generic_perform_write+0x469/0x6c0 mm/filemap.c:3147
__generic_file_write_iter+0x26e/0x630 mm/filemap.c:3264
ext4_file_write_iter+0x390/0x1450 fs/ext4/file.c:266
call_write_iter include/linux/fs.h:1807 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6af/0x9d0 fs/read_write.c:487
vfs_write+0x1fc/0x560 fs/read_write.c:549
kernel_write+0xab/0x120 fs/read_write.c:526
p9_fd_write net/9p/trans_fd.c:432 [inline]
p9_write_work+0x6f1/0xd50 net/9p/trans_fd.c:481
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

Allocated by task 4438:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc+0x14e/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:518 [inline]
p9_fcall_alloc+0x1e/0x90 net/9p/client.c:237
p9_tag_alloc net/9p/client.c:266 [inline]
p9_client_prepare_req.part.8+0x107/0xa00 net/9p/client.c:647
p9_client_prepare_req net/9p/client.c:682 [inline]
p9_client_rpc+0x247/0x1420 net/9p/client.c:682
p9_client_version net/9p/client.c:897 [inline]
p9_client_create+0xd76/0x1631 net/9p/client.c:981
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
legacy_get_tree+0x131/0x460 fs/fs_context.c:674
vfs_get_tree+0x1cb/0x5c0 fs/super.c:1762
do_new_mount fs/namespace.c:2629 [inline]
do_mount+0x6f2/0x1e20 fs/namespace.c:2953
ksys_mount+0x12d/0x140 fs/namespace.c:3169
__do_sys_mount fs/namespace.c:3183 [inline]
__se_sys_mount fs/namespace.c:3180 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3180
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 4438:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
p9_free_req+0xb5/0x120 net/9p/client.c:338
p9_client_rpc+0xb20/0x1420 net/9p/client.c:746
p9_client_version net/9p/client.c:897 [inline]
p9_client_create+0xd76/0x1631 net/9p/client.c:981
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
legacy_get_tree+0x131/0x460 fs/fs_context.c:674
vfs_get_tree+0x1cb/0x5c0 fs/super.c:1762
do_new_mount fs/namespace.c:2629 [inline]
do_mount+0x6f2/0x1e20 fs/namespace.c:2953
ksys_mount+0x12d/0x140 fs/namespace.c:3169
__do_sys_mount fs/namespace.c:3183 [inline]
__se_sys_mount fs/namespace.c:3180 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3180
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff8801ad780d40
which belongs to the cache kmalloc-16384 of size 16384
The buggy address is located 32 bytes inside of
16384-byte region [ffff8801ad780d40, ffff8801ad784d40)
The buggy address belongs to the page:
page:ffffea0006b5e000 count:1 mapcount:0 mapping:ffff8801dac02200 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00072e3008 ffffea0006c75408 ffff8801dac02200
raw: 0000000000000000 ffff8801ad780d40 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8801ad780c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801ad780c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ad780d00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801ad780d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801ad780e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Aleksandr Nogikh

unread,
Mar 29, 2023, 4:00:37 AM3/29/23
to syzkaller-bugs
#syz invalid

syzbot

unread,
Mar 29, 2023, 4:00:42 AM3/29/23
to nog...@google.com, nog...@google.com, syzkall...@googlegroups.com
> #syz invalid

I see the command but can't find the corresponding bug.
Please resend the email to syzbo...@syzkaller.appspotmail.com address
that is the sender of the bug report (also present in the Reported-by tag).
> --
> 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-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/1175788c-b4fb-444e-a030-967337cc95aan%40googlegroups.com.

syzbot

unread,
Apr 14, 2023, 4:17:30 AM4/14/23
to syzkall...@googlegroups.com
Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.
Reply all
Reply to author
Forward
0 new messages