* [syzbot] KASAN: use-after-free Write in put_ucounts
@ 2021-07-17 6:22 syzbot
[not found] ` <20210719094432.425-1-hdanton@sina.com>
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: syzbot @ 2021-07-17 6:22 UTC (permalink / raw)
To: ebiederm, legion, linux-kernel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 3dbdb38e2869 Merge branch 'for-5.14' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1541de9c300000
kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757
dashboard link: https://syzkaller.appspot.com/bug?extid=b6e65bd125a05f803d6b
userspace arch: i386
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
BUG: KASAN: use-after-free in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline]
BUG: KASAN: use-after-free in put_ucounts+0x1c/0x150 kernel/ucount.c:196
Write of size 4 at addr ffff88801c86cc1c by task kworker/u4:3/166
CPU: 0 PID: 166 Comm: kworker/u4:3 Not tainted 5.13.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: bat_events batadv_nc_worker
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:96
print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:436
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline]
put_ucounts+0x1c/0x150 kernel/ucount.c:196
put_cred_rcu+0x27a/0x520 kernel/cred.c:124
rcu_do_batch kernel/rcu/tree.c:2558 [inline]
rcu_core+0x7ab/0x1380 kernel/rcu/tree.c:2793
__do_softirq+0x29b/0x9bd kernel/softirq.c:558
invoke_softirq kernel/softirq.c:432 [inline]
__irq_exit_rcu+0x16e/0x1c0 kernel/softirq.c:636
irq_exit_rcu+0x5/0x20 kernel/softirq.c:648
sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100
</IRQ>
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638
RIP: 0010:lock_acquire+0x1ef/0x510 kernel/locking/lockdep.c:5593
Code: e1 a6 7e 83 f8 01 0f 85 a6 02 00 00 9c 58 f6 c4 02 0f 85 91 02 00 00 48 83 7c 24 08 00 74 01 fb 48 b8 00 00 00 00 00 fc ff df <48> 01 c3 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 48 8b 84 24
RSP: 0018:ffffc900010bfba8 EFLAGS: 00000206
RAX: dffffc0000000000 RBX: 1ffff92000217f77 RCX: 3f6e7590f6a9846c
RDX: 1ffff1100283613d RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff9049d8a7
R10: fffffbfff2093b14 R11: 0000000000000000 R12: 0000000000000002
R13: 0000000000000000 R14: ffffffff8c17bb80 R15: 0000000000000000
rcu_lock_acquire include/linux/rcupdate.h:267 [inline]
rcu_read_lock include/linux/rcupdate.h:671 [inline]
batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:404 [inline]
batadv_nc_worker+0x12d/0xe50 net/batman-adv/network-coding.c:715
process_one_work+0x98d/0x1630 kernel/workqueue.c:2276
worker_thread+0x658/0x11f0 kernel/workqueue.c:2422
kthread+0x3e5/0x4d0 kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
Allocated by task 8622:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:434 [inline]
____kasan_kmalloc mm/kasan/common.c:513 [inline]
____kasan_kmalloc mm/kasan/common.c:472 [inline]
__kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:522
kmalloc include/linux/slab.h:591 [inline]
kzalloc include/linux/slab.h:721 [inline]
alloc_ucounts+0x23d/0x5b0 kernel/ucount.c:169
set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684
copy_creds+0x853/0xb20 kernel/cred.c:375
copy_process+0x1413/0x74c0 kernel/fork.c:1992
kernel_clone+0xe7/0xab0 kernel/fork.c:2509
__do_compat_sys_ia32_clone+0xac/0xe0 arch/x86/kernel/sys_ia32.c:254
do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
do_int80_syscall_32+0x46/0x90 arch/x86/entry/common.c:132
entry_INT80_compat+0x71/0x76 arch/x86/entry/entry_64_compat.S:413
Last potentially related work creation:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348
insert_work+0x48/0x370 kernel/workqueue.c:1332
__queue_work+0x5c1/0xed0 kernel/workqueue.c:1498
queue_work_on+0xee/0x110 kernel/workqueue.c:1525
queue_work include/linux/workqueue.h:507 [inline]
call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435
kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618
kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208
uevent_store+0x20/0x50 drivers/base/core.c:2370
dev_attr_store+0x50/0x80 drivers/base/core.c:2071
sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139
kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296
call_write_iter include/linux/fs.h:2114 [inline]
new_sync_write+0x426/0x650 fs/read_write.c:518
vfs_write+0x796/0xa30 fs/read_write.c:605
ksys_write+0x12d/0x250 fs/read_write.c:658
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Second to last potentially related work creation:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348
insert_work+0x48/0x370 kernel/workqueue.c:1332
__queue_work+0x5c1/0xed0 kernel/workqueue.c:1498
queue_work_on+0xee/0x110 kernel/workqueue.c:1525
queue_work include/linux/workqueue.h:507 [inline]
call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435
kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618
kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208
uevent_store+0x42/0x90 drivers/base/bus.c:585
drv_attr_store+0x6d/0xa0 drivers/base/bus.c:77
sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139
kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296
call_write_iter include/linux/fs.h:2114 [inline]
new_sync_write+0x426/0x650 fs/read_write.c:518
vfs_write+0x796/0xa30 fs/read_write.c:605
ksys_write+0x12d/0x250 fs/read_write.c:658
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88801c86cc00
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 28 bytes inside of
192-byte region [ffff88801c86cc00, ffff88801c86ccc0)
The buggy address belongs to the page:
page:ffffea0000721b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88801c86cc00 pfn:0x1c86c
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffffea00009f0e48 ffffea00009cd188 ffff888011041a00
raw: ffff88801c86cc00 000000000010000b 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 7975119940, free_ts 7474437105
prep_new_page mm/page_alloc.c:2445 [inline]
get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4178
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5386
alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2147
alloc_pages+0x238/0x2a0 mm/mempolicy.c:2270
alloc_slab_page mm/slub.c:1702 [inline]
allocate_slab+0x32b/0x4c0 mm/slub.c:1842
new_slab mm/slub.c:1905 [inline]
new_slab_objects mm/slub.c:2651 [inline]
___slab_alloc+0x4ba/0x820 mm/slub.c:2814
__slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2854
slab_alloc_node mm/slub.c:2936 [inline]
slab_alloc mm/slub.c:2978 [inline]
kmem_cache_alloc_trace+0x325/0x3c0 mm/slub.c:2995
kmalloc include/linux/slab.h:591 [inline]
kzalloc include/linux/slab.h:721 [inline]
call_usermodehelper_setup+0x97/0x340 kernel/umh.c:365
kobject_uevent_env+0xf73/0x1650 lib/kobject_uevent.c:614
device_add+0xb71/0x2100 drivers/base/core.c:3305
register_virtio_device+0x1e1/0x2c0 drivers/virtio/virtio.c:363
virtio_pci_probe+0x203/0x390 drivers/virtio/virtio_pci_common.c:552
local_pci_probe+0xdb/0x190 drivers/pci/pci-driver.c:309
pci_call_probe drivers/pci/pci-driver.c:366 [inline]
__pci_device_probe drivers/pci/pci-driver.c:391 [inline]
pci_device_probe+0x3dd/0x6f0 drivers/pci/pci-driver.c:434
really_probe+0x291/0xf60 drivers/base/dd.c:576
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1355 [inline]
free_pcp_prepare+0x2c5/0x780 mm/page_alloc.c:1406
free_unref_page_prepare mm/page_alloc.c:3341 [inline]
free_unref_page+0x19/0x690 mm/page_alloc.c:3420
__vunmap+0x783/0xb70 mm/vmalloc.c:2569
free_work+0x58/0x70 mm/vmalloc.c:80
process_one_work+0x98d/0x1630 kernel/workqueue.c:2276
worker_thread+0x658/0x11f0 kernel/workqueue.c:2422
kthread+0x3e5/0x4d0 kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
Memory state around the buggy address:
ffff88801c86cb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88801c86cb80: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88801c86cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801c86cc80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88801c86cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
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.
^ permalink raw reply [flat|nested] 8+ messages in thread[parent not found: <20210719094432.425-1-hdanton@sina.com>]
* Re: [syzbot] KASAN: use-after-free Write in put_ucounts [not found] ` <20210719094432.425-1-hdanton@sina.com> @ 2021-07-19 17:24 ` Eric W. Biederman 2021-07-24 17:57 ` Alexey Gladkov [not found] ` <20210720041451.766-1-hdanton@sina.com> 1 sibling, 1 reply; 8+ messages in thread From: Eric W. Biederman @ 2021-07-19 17:24 UTC (permalink / raw) To: Hillf Danton; +Cc: syzbot, legion, linux-kernel, syzkaller-bugs Hillf Danton <hdanton@sina.com> writes: > On Fri, 16 Jul 2021 23:22:19 -0700 >>syzbot found the following issue on: >> >>HEAD commit: 3dbdb38e2869 Merge branch 'for-5.14' of git://git.kernel.o.. >>git tree: upstream >>console output: https://syzkaller.appspot.com/x/log.txt?x=1541de9c300000 >>kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757 >>dashboard link: https://syzkaller.appspot.com/bug?extid=b6e65bd125a05f803d6b >>userspace arch: i386 >> >>Unfortunately, I don't have any reproducer for this issue yet. >> >>IMPORTANT: if you fix the issue, please add the following tag to the commit: >>Reported-by: syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com >> >>================================================================== >>BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:101 [inline] >>BUG: KASAN: use-after-free in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] >>BUG: KASAN: use-after-free in put_ucounts+0x1c/0x150 kernel/ucount.c:196 >>Write of size 4 at addr ffff88801c86cc1c by task kworker/u4:3/166 >> >>CPU: 0 PID: 166 Comm: kworker/u4:3 Not tainted 5.13.0-syzkaller #0 >>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >>Workqueue: bat_events batadv_nc_worker >>Call Trace: >> <IRQ> >> __dump_stack lib/dump_stack.c:79 [inline] >> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:96 >> print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233 >> __kasan_report mm/kasan/report.c:419 [inline] >> kasan_report.cold+0x83/0xdf mm/kasan/report.c:436 >> check_region_inline mm/kasan/generic.c:183 [inline] >> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 >> instrument_atomic_read_write include/linux/instrumented.h:101 [inline] >> atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] >> put_ucounts+0x1c/0x150 kernel/ucount.c:196 >> put_cred_rcu+0x27a/0x520 kernel/cred.c:124 >> rcu_do_batch kernel/rcu/tree.c:2558 [inline] >> rcu_core+0x7ab/0x1380 kernel/rcu/tree.c:2793 >> __do_softirq+0x29b/0x9bd kernel/softirq.c:558 >> invoke_softirq kernel/softirq.c:432 [inline] >> __irq_exit_rcu+0x16e/0x1c0 kernel/softirq.c:636 >> irq_exit_rcu+0x5/0x20 kernel/softirq.c:648 >> sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100 >> </IRQ> >> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 >>RIP: 0010:lock_acquire+0x1ef/0x510 kernel/locking/lockdep.c:5593 >>Code: e1 a6 7e 83 f8 01 0f 85 a6 02 00 00 9c 58 f6 c4 02 0f 85 91 02 00 00 48 83 7c 24 08 00 74 01 fb 48 b8 00 00 00 00 00 fc ff df <48> 01 c3 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 48 8b 84 24 >>RSP: 0018:ffffc900010bfba8 EFLAGS: 00000206 >>RAX: dffffc0000000000 RBX: 1ffff92000217f77 RCX: 3f6e7590f6a9846c >>RDX: 1ffff1100283613d RSI: 0000000000000000 RDI: 0000000000000000 >>RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff9049d8a7 >>R10: fffffbfff2093b14 R11: 0000000000000000 R12: 0000000000000002 >>R13: 0000000000000000 R14: ffffffff8c17bb80 R15: 0000000000000000 >> rcu_lock_acquire include/linux/rcupdate.h:267 [inline] >> rcu_read_lock include/linux/rcupdate.h:671 [inline] >> batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:404 [inline] >> batadv_nc_worker+0x12d/0xe50 net/batman-adv/network-coding.c:715 >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 >> >>Allocated by task 8622: >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> kasan_set_track mm/kasan/common.c:46 [inline] >> set_alloc_info mm/kasan/common.c:434 [inline] >> ____kasan_kmalloc mm/kasan/common.c:513 [inline] >> ____kasan_kmalloc mm/kasan/common.c:472 [inline] >> __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:522 >> kmalloc include/linux/slab.h:591 [inline] >> kzalloc include/linux/slab.h:721 [inline] >> alloc_ucounts+0x23d/0x5b0 kernel/ucount.c:169 >> set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684 >> copy_creds+0x853/0xb20 kernel/cred.c:375 >> copy_process+0x1413/0x74c0 kernel/fork.c:1992 >> kernel_clone+0xe7/0xab0 kernel/fork.c:2509 >> __do_compat_sys_ia32_clone+0xac/0xe0 arch/x86/kernel/sys_ia32.c:254 >> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] >> do_int80_syscall_32+0x46/0x90 arch/x86/entry/common.c:132 >> entry_INT80_compat+0x71/0x76 arch/x86/entry/entry_64_compat.S:413 >> >>Last potentially related work creation: >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 >> insert_work+0x48/0x370 kernel/workqueue.c:1332 >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 >> queue_work include/linux/workqueue.h:507 [inline] >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 >> uevent_store+0x20/0x50 drivers/base/core.c:2370 >> dev_attr_store+0x50/0x80 drivers/base/core.c:2071 >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 >> call_write_iter include/linux/fs.h:2114 [inline] >> new_sync_write+0x426/0x650 fs/read_write.c:518 >> vfs_write+0x796/0xa30 fs/read_write.c:605 >> ksys_write+0x12d/0x250 fs/read_write.c:658 >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 >> entry_SYSCALL_64_after_hwframe+0x44/0xae >> >>Second to last potentially related work creation: >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 >> insert_work+0x48/0x370 kernel/workqueue.c:1332 >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 >> queue_work include/linux/workqueue.h:507 [inline] >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 >> uevent_store+0x42/0x90 drivers/base/bus.c:585 >> drv_attr_store+0x6d/0xa0 drivers/base/bus.c:77 >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 >> call_write_iter include/linux/fs.h:2114 [inline] >> new_sync_write+0x426/0x650 fs/read_write.c:518 >> vfs_write+0x796/0xa30 fs/read_write.c:605 >> ksys_write+0x12d/0x250 fs/read_write.c:658 >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 >> entry_SYSCALL_64_after_hwframe+0x44/0xae >> >>The buggy address belongs to the object at ffff88801c86cc00 >> which belongs to the cache kmalloc-192 of size 192 >>The buggy address is located 28 bytes inside of >> 192-byte region [ffff88801c86cc00, ffff88801c86ccc0) >>The buggy address belongs to the page: >>page:ffffea0000721b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88801c86cc00 pfn:0x1c86c >>flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) >>raw: 00fff00000000200 ffffea00009f0e48 ffffea00009cd188 ffff888011041a00 >>raw: ffff88801c86cc00 000000000010000b 00000001ffffffff 0000000000000000 >>page dumped because: kasan: bad access detected >>page_owner tracks the page as allocated >>page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 7975119940, free_ts 7474437105 >> prep_new_page mm/page_alloc.c:2445 [inline] >> get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4178 >> __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5386 >> alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2147 >> alloc_pages+0x238/0x2a0 mm/mempolicy.c:2270 >> alloc_slab_page mm/slub.c:1702 [inline] >> allocate_slab+0x32b/0x4c0 mm/slub.c:1842 >> new_slab mm/slub.c:1905 [inline] >> new_slab_objects mm/slub.c:2651 [inline] >> ___slab_alloc+0x4ba/0x820 mm/slub.c:2814 >> __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2854 >> slab_alloc_node mm/slub.c:2936 [inline] >> slab_alloc mm/slub.c:2978 [inline] >> kmem_cache_alloc_trace+0x325/0x3c0 mm/slub.c:2995 >> kmalloc include/linux/slab.h:591 [inline] >> kzalloc include/linux/slab.h:721 [inline] >> call_usermodehelper_setup+0x97/0x340 kernel/umh.c:365 >> kobject_uevent_env+0xf73/0x1650 lib/kobject_uevent.c:614 >> device_add+0xb71/0x2100 drivers/base/core.c:3305 >> register_virtio_device+0x1e1/0x2c0 drivers/virtio/virtio.c:363 >> virtio_pci_probe+0x203/0x390 drivers/virtio/virtio_pci_common.c:552 >> local_pci_probe+0xdb/0x190 drivers/pci/pci-driver.c:309 >> pci_call_probe drivers/pci/pci-driver.c:366 [inline] >> __pci_device_probe drivers/pci/pci-driver.c:391 [inline] >> pci_device_probe+0x3dd/0x6f0 drivers/pci/pci-driver.c:434 >> really_probe+0x291/0xf60 drivers/base/dd.c:576 >>page last free stack trace: >> reset_page_owner include/linux/page_owner.h:24 [inline] >> free_pages_prepare mm/page_alloc.c:1355 [inline] >> free_pcp_prepare+0x2c5/0x780 mm/page_alloc.c:1406 >> free_unref_page_prepare mm/page_alloc.c:3341 [inline] >> free_unref_page+0x19/0x690 mm/page_alloc.c:3420 >> __vunmap+0x783/0xb70 mm/vmalloc.c:2569 >> free_work+0x58/0x70 mm/vmalloc.c:80 >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 >> >>Memory state around the buggy address: >> ffff88801c86cb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> ffff88801c86cb80: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc >>>ffff88801c86cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> ^ >> ffff88801c86cc80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >> ffff88801c86cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>================================================================== > > To fix the uaf, add a couple of changes. Now only for thoughts. > > 1/ s/atomic_add_negative/atomic_inc_not_zero/ to correct the get > method. I really don't think so. The use of atomic_add_negative is very deliberate. Changing that fundamentally changes the algorithm into used to keep track of things. Definitely not something to lead with. Before it even makes sense to talk about how to change the code, a plausible explanation for how a use after free happens is needed. That explanation should account for the fact this code was in linux-next the since last -rc1 without any kind of issue with the test code. Did something change in the test infrastructure? Is there another bug that is stomping memory and making it look like this code is buggy? I haven't had a chance to dig in in detail (everyone in my house is sick). I am hoping that Alexey Gladkov will have that time soon. What I can say is that a solution that leads with your code is fundamentally misdesigned and everything needs to change, and there is no explanation for why it all needs to change is probably not a solution to the problem. Eric ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] KASAN: use-after-free Write in put_ucounts 2021-07-19 17:24 ` Eric W. Biederman @ 2021-07-24 17:57 ` Alexey Gladkov 2021-07-25 0:32 ` Hillf Danton 0 siblings, 1 reply; 8+ messages in thread From: Alexey Gladkov @ 2021-07-24 17:57 UTC (permalink / raw) To: Eric W. Biederman; +Cc: Hillf Danton, syzbot, linux-kernel, syzkaller-bugs On Mon, Jul 19, 2021 at 12:24:41PM -0500, Eric W. Biederman wrote: > Hillf Danton <hdanton@sina.com> writes: > > > On Fri, 16 Jul 2021 23:22:19 -0700 > >>syzbot found the following issue on: > >> > >>HEAD commit: 3dbdb38e2869 Merge branch 'for-5.14' of git://git.kernel.o.. > >>git tree: upstream > >>console output: https://syzkaller.appspot.com/x/log.txt?x=1541de9c300000 > >>kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757 > >>dashboard link: https://syzkaller.appspot.com/bug?extid=b6e65bd125a05f803d6b > >>userspace arch: i386 > >> > >>Unfortunately, I don't have any reproducer for this issue yet. > >> > >>IMPORTANT: if you fix the issue, please add the following tag to the commit: > >>Reported-by: syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com > >> > >>================================================================== > >>BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:101 [inline] > >>BUG: KASAN: use-after-free in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] > >>BUG: KASAN: use-after-free in put_ucounts+0x1c/0x150 kernel/ucount.c:196 > >>Write of size 4 at addr ffff88801c86cc1c by task kworker/u4:3/166 > >> > >>CPU: 0 PID: 166 Comm: kworker/u4:3 Not tainted 5.13.0-syzkaller #0 > >>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > >>Workqueue: bat_events batadv_nc_worker > >>Call Trace: > >> <IRQ> > >> __dump_stack lib/dump_stack.c:79 [inline] > >> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:96 > >> print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233 > >> __kasan_report mm/kasan/report.c:419 [inline] > >> kasan_report.cold+0x83/0xdf mm/kasan/report.c:436 > >> check_region_inline mm/kasan/generic.c:183 [inline] > >> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 > >> instrument_atomic_read_write include/linux/instrumented.h:101 [inline] > >> atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] > >> put_ucounts+0x1c/0x150 kernel/ucount.c:196 > >> put_cred_rcu+0x27a/0x520 kernel/cred.c:124 > >> rcu_do_batch kernel/rcu/tree.c:2558 [inline] > >> rcu_core+0x7ab/0x1380 kernel/rcu/tree.c:2793 > >> __do_softirq+0x29b/0x9bd kernel/softirq.c:558 > >> invoke_softirq kernel/softirq.c:432 [inline] > >> __irq_exit_rcu+0x16e/0x1c0 kernel/softirq.c:636 > >> irq_exit_rcu+0x5/0x20 kernel/softirq.c:648 > >> sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100 > >> </IRQ> > >> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 > >>RIP: 0010:lock_acquire+0x1ef/0x510 kernel/locking/lockdep.c:5593 > >>Code: e1 a6 7e 83 f8 01 0f 85 a6 02 00 00 9c 58 f6 c4 02 0f 85 91 02 00 00 48 83 7c 24 08 00 74 01 fb 48 b8 00 00 00 00 00 fc ff df <48> 01 c3 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 48 8b 84 24 > >>RSP: 0018:ffffc900010bfba8 EFLAGS: 00000206 > >>RAX: dffffc0000000000 RBX: 1ffff92000217f77 RCX: 3f6e7590f6a9846c > >>RDX: 1ffff1100283613d RSI: 0000000000000000 RDI: 0000000000000000 > >>RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff9049d8a7 > >>R10: fffffbfff2093b14 R11: 0000000000000000 R12: 0000000000000002 > >>R13: 0000000000000000 R14: ffffffff8c17bb80 R15: 0000000000000000 > >> rcu_lock_acquire include/linux/rcupdate.h:267 [inline] > >> rcu_read_lock include/linux/rcupdate.h:671 [inline] > >> batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:404 [inline] > >> batadv_nc_worker+0x12d/0xe50 net/batman-adv/network-coding.c:715 > >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 > >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 > >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 > >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 > >> > >>Allocated by task 8622: > >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 > >> kasan_set_track mm/kasan/common.c:46 [inline] > >> set_alloc_info mm/kasan/common.c:434 [inline] > >> ____kasan_kmalloc mm/kasan/common.c:513 [inline] > >> ____kasan_kmalloc mm/kasan/common.c:472 [inline] > >> __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:522 > >> kmalloc include/linux/slab.h:591 [inline] > >> kzalloc include/linux/slab.h:721 [inline] > >> alloc_ucounts+0x23d/0x5b0 kernel/ucount.c:169 > >> set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684 > >> copy_creds+0x853/0xb20 kernel/cred.c:375 > >> copy_process+0x1413/0x74c0 kernel/fork.c:1992 > >> kernel_clone+0xe7/0xab0 kernel/fork.c:2509 > >> __do_compat_sys_ia32_clone+0xac/0xe0 arch/x86/kernel/sys_ia32.c:254 > >> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] > >> do_int80_syscall_32+0x46/0x90 arch/x86/entry/common.c:132 > >> entry_INT80_compat+0x71/0x76 arch/x86/entry/entry_64_compat.S:413 > >> > >>Last potentially related work creation: > >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 > >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 > >> insert_work+0x48/0x370 kernel/workqueue.c:1332 > >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 > >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 > >> queue_work include/linux/workqueue.h:507 [inline] > >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 > >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 > >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 > >> uevent_store+0x20/0x50 drivers/base/core.c:2370 > >> dev_attr_store+0x50/0x80 drivers/base/core.c:2071 > >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 > >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 > >> call_write_iter include/linux/fs.h:2114 [inline] > >> new_sync_write+0x426/0x650 fs/read_write.c:518 > >> vfs_write+0x796/0xa30 fs/read_write.c:605 > >> ksys_write+0x12d/0x250 fs/read_write.c:658 > >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] > >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > >> entry_SYSCALL_64_after_hwframe+0x44/0xae > >> > >>Second to last potentially related work creation: > >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 > >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 > >> insert_work+0x48/0x370 kernel/workqueue.c:1332 > >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 > >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 > >> queue_work include/linux/workqueue.h:507 [inline] > >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 > >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 > >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 > >> uevent_store+0x42/0x90 drivers/base/bus.c:585 > >> drv_attr_store+0x6d/0xa0 drivers/base/bus.c:77 > >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 > >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 > >> call_write_iter include/linux/fs.h:2114 [inline] > >> new_sync_write+0x426/0x650 fs/read_write.c:518 > >> vfs_write+0x796/0xa30 fs/read_write.c:605 > >> ksys_write+0x12d/0x250 fs/read_write.c:658 > >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] > >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > >> entry_SYSCALL_64_after_hwframe+0x44/0xae > >> > >>The buggy address belongs to the object at ffff88801c86cc00 > >> which belongs to the cache kmalloc-192 of size 192 > >>The buggy address is located 28 bytes inside of > >> 192-byte region [ffff88801c86cc00, ffff88801c86ccc0) > >>The buggy address belongs to the page: > >>page:ffffea0000721b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88801c86cc00 pfn:0x1c86c > >>flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) > >>raw: 00fff00000000200 ffffea00009f0e48 ffffea00009cd188 ffff888011041a00 > >>raw: ffff88801c86cc00 000000000010000b 00000001ffffffff 0000000000000000 > >>page dumped because: kasan: bad access detected > >>page_owner tracks the page as allocated > >>page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 7975119940, free_ts 7474437105 > >> prep_new_page mm/page_alloc.c:2445 [inline] > >> get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4178 > >> __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5386 > >> alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2147 > >> alloc_pages+0x238/0x2a0 mm/mempolicy.c:2270 > >> alloc_slab_page mm/slub.c:1702 [inline] > >> allocate_slab+0x32b/0x4c0 mm/slub.c:1842 > >> new_slab mm/slub.c:1905 [inline] > >> new_slab_objects mm/slub.c:2651 [inline] > >> ___slab_alloc+0x4ba/0x820 mm/slub.c:2814 > >> __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2854 > >> slab_alloc_node mm/slub.c:2936 [inline] > >> slab_alloc mm/slub.c:2978 [inline] > >> kmem_cache_alloc_trace+0x325/0x3c0 mm/slub.c:2995 > >> kmalloc include/linux/slab.h:591 [inline] > >> kzalloc include/linux/slab.h:721 [inline] > >> call_usermodehelper_setup+0x97/0x340 kernel/umh.c:365 > >> kobject_uevent_env+0xf73/0x1650 lib/kobject_uevent.c:614 > >> device_add+0xb71/0x2100 drivers/base/core.c:3305 > >> register_virtio_device+0x1e1/0x2c0 drivers/virtio/virtio.c:363 > >> virtio_pci_probe+0x203/0x390 drivers/virtio/virtio_pci_common.c:552 > >> local_pci_probe+0xdb/0x190 drivers/pci/pci-driver.c:309 > >> pci_call_probe drivers/pci/pci-driver.c:366 [inline] > >> __pci_device_probe drivers/pci/pci-driver.c:391 [inline] > >> pci_device_probe+0x3dd/0x6f0 drivers/pci/pci-driver.c:434 > >> really_probe+0x291/0xf60 drivers/base/dd.c:576 > >>page last free stack trace: > >> reset_page_owner include/linux/page_owner.h:24 [inline] > >> free_pages_prepare mm/page_alloc.c:1355 [inline] > >> free_pcp_prepare+0x2c5/0x780 mm/page_alloc.c:1406 > >> free_unref_page_prepare mm/page_alloc.c:3341 [inline] > >> free_unref_page+0x19/0x690 mm/page_alloc.c:3420 > >> __vunmap+0x783/0xb70 mm/vmalloc.c:2569 > >> free_work+0x58/0x70 mm/vmalloc.c:80 > >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 > >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 > >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 > >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 > >> > >>Memory state around the buggy address: > >> ffff88801c86cb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> ffff88801c86cb80: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc > >>>ffff88801c86cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > >> ^ > >> ffff88801c86cc80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc > >> ffff88801c86cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >>================================================================== > > > > To fix the uaf, add a couple of changes. Now only for thoughts. > > > > > 1/ s/atomic_add_negative/atomic_inc_not_zero/ to correct the get > > method. > > I really don't think so. The use of atomic_add_negative is very > deliberate. Changing that fundamentally changes the algorithm into used > to keep track of things. Definitely not something to lead with. > > Before it even makes sense to talk about how to change the code, > a plausible explanation for how a use after free happens is needed. > > That explanation should account for the fact this code was in linux-next > the since last -rc1 without any kind of issue with the test code. > > Did something change in the test infrastructure? Is there another > bug that is stomping memory and making it look like this code is buggy? > > I haven't had a chance to dig in in detail (everyone in my house is > sick). I am hoping that Alexey Gladkov will have that time soon. It's better to look at another report. I think it illustrates regression better: https://syzkaller.appspot.com/bug?id=edc996c68de05701cbd709b1ee99344defb94334 Hillf Danton is right about race condition. The situation is rare because most often alloc_ucounts() and put_ucounts() are executed under rcu lock. I spent a few days but couldn't reproduce it. I did this regression in the b6c336528926 ("Use atomic_t for ucounts reference counting"). Before to this, the reference count check was under spin_lock. Now spin_lock in alloc_ucounts() doesn't protect find_ucounts() from parallel put_ucounts(). Atomically increasing the reference count solves the problem between get_accounts() and put_accounts(), but find_ucounts() is not protected. We need to either return spin_lock to the beginning of put_ucounts(), or recycle alloc_ucounts(). > What I can say is that a solution that leads with your code is > fundamentally misdesigned and everything needs to change, and there > is no explanation for why it all needs to change is probably not a > solution to the problem. The proposed patch is incorrect because in case of an overflow of the reference count in find_get_ucounts(), we will get a counter leak. -- Rgrds, legion ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] KASAN: use-after-free Write in put_ucounts 2021-07-24 17:57 ` Alexey Gladkov @ 2021-07-25 0:32 ` Hillf Danton 0 siblings, 0 replies; 8+ messages in thread From: Hillf Danton @ 2021-07-25 0:32 UTC (permalink / raw) To: Alexey Gladkov Cc: Eric W. Biederman, Hillf Danton, syzbot, linux-mm, linux-kernel, syzkaller-bugs On Sat, 24 Jul 2021 19:57:24 +0200 Alexey Gladkov wrote: >On Mon, Jul 19, 2021 at 12:24:41PM -0500, Eric W. Biederman wrote: >> Hillf Danton <hdanton@sina.com> writes: >> >> > On Fri, 16 Jul 2021 23:22:19 -0700 >> >>syzbot found the following issue on: >> >> >> >>HEAD commit: 3dbdb38e2869 Merge branch 'for-5.14' of git://git.kernel.o.. >> >>git tree: upstream >> >>console output: https://syzkaller.appspot.com/x/log.txt?x=1541de9c300000 >> >>kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757 >> >>dashboard link: https://syzkaller.appspot.com/bug?extid=b6e65bd125a05f803d6b >> >>userspace arch: i386 >> >> >> >>Unfortunately, I don't have any reproducer for this issue yet. >> >> >> >>IMPORTANT: if you fix the issue, please add the following tag to the commit: >> >>Reported-by: syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com >> >> >> >>================================================================== >> >>BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:101 [inline] >> >>BUG: KASAN: use-after-free in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] >> >>BUG: KASAN: use-after-free in put_ucounts+0x1c/0x150 kernel/ucount.c:196 >> >>Write of size 4 at addr ffff88801c86cc1c by task kworker/u4:3/166 >> >> >> >>CPU: 0 PID: 166 Comm: kworker/u4:3 Not tainted 5.13.0-syzkaller #0 >> >>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >> >>Workqueue: bat_events batadv_nc_worker >> >>Call Trace: >> >> <IRQ> >> >> __dump_stack lib/dump_stack.c:79 [inline] >> >> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:96 >> >> print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233 >> >> __kasan_report mm/kasan/report.c:419 [inline] >> >> kasan_report.cold+0x83/0xdf mm/kasan/report.c:436 >> >> check_region_inline mm/kasan/generic.c:183 [inline] >> >> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 >> >> instrument_atomic_read_write include/linux/instrumented.h:101 [inline] >> >> atomic_dec_and_test include/asm-generic/atomic-instrumented.h:542 [inline] >> >> put_ucounts+0x1c/0x150 kernel/ucount.c:196 >> >> put_cred_rcu+0x27a/0x520 kernel/cred.c:124 >> >> rcu_do_batch kernel/rcu/tree.c:2558 [inline] >> >> rcu_core+0x7ab/0x1380 kernel/rcu/tree.c:2793 >> >> __do_softirq+0x29b/0x9bd kernel/softirq.c:558 >> >> invoke_softirq kernel/softirq.c:432 [inline] >> >> __irq_exit_rcu+0x16e/0x1c0 kernel/softirq.c:636 >> >> irq_exit_rcu+0x5/0x20 kernel/softirq.c:648 >> >> sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100 >> >> </IRQ> >> >> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 >> >>RIP: 0010:lock_acquire+0x1ef/0x510 kernel/locking/lockdep.c:5593 >> >>Code: e1 a6 7e 83 f8 01 0f 85 a6 02 00 00 9c 58 f6 c4 02 0f 85 91 02 00 00 48 83 7c 24 08 00 74 01 fb 48 b8 00 00 00 00 00 fc ff df <48> 01 c3 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 48 8b 84 24 >> >>RSP: 0018:ffffc900010bfba8 EFLAGS: 00000206 >> >>RAX: dffffc0000000000 RBX: 1ffff92000217f77 RCX: 3f6e7590f6a9846c >> >>RDX: 1ffff1100283613d RSI: 0000000000000000 RDI: 0000000000000000 >> >>RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff9049d8a7 >> >>R10: fffffbfff2093b14 R11: 0000000000000000 R12: 0000000000000002 >> >>R13: 0000000000000000 R14: ffffffff8c17bb80 R15: 0000000000000000 >> >> rcu_lock_acquire include/linux/rcupdate.h:267 [inline] >> >> rcu_read_lock include/linux/rcupdate.h:671 [inline] >> >> batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:404 [inline] >> >> batadv_nc_worker+0x12d/0xe50 net/batman-adv/network-coding.c:715 >> >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 >> >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 >> >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 >> >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 >> >> >> >>Allocated by task 8622: >> >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> >> kasan_set_track mm/kasan/common.c:46 [inline] >> >> set_alloc_info mm/kasan/common.c:434 [inline] >> >> ____kasan_kmalloc mm/kasan/common.c:513 [inline] >> >> ____kasan_kmalloc mm/kasan/common.c:472 [inline] >> >> __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:522 >> >> kmalloc include/linux/slab.h:591 [inline] >> >> kzalloc include/linux/slab.h:721 [inline] >> >> alloc_ucounts+0x23d/0x5b0 kernel/ucount.c:169 >> >> set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684 >> >> copy_creds+0x853/0xb20 kernel/cred.c:375 >> >> copy_process+0x1413/0x74c0 kernel/fork.c:1992 >> >> kernel_clone+0xe7/0xab0 kernel/fork.c:2509 >> >> __do_compat_sys_ia32_clone+0xac/0xe0 arch/x86/kernel/sys_ia32.c:254 >> >> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] >> >> do_int80_syscall_32+0x46/0x90 arch/x86/entry/common.c:132 >> >> entry_INT80_compat+0x71/0x76 arch/x86/entry/entry_64_compat.S:413 >> >> >> >>Last potentially related work creation: >> >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 >> >> insert_work+0x48/0x370 kernel/workqueue.c:1332 >> >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 >> >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 >> >> queue_work include/linux/workqueue.h:507 [inline] >> >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 >> >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 >> >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 >> >> uevent_store+0x20/0x50 drivers/base/core.c:2370 >> >> dev_attr_store+0x50/0x80 drivers/base/core.c:2071 >> >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 >> >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 >> >> call_write_iter include/linux/fs.h:2114 [inline] >> >> new_sync_write+0x426/0x650 fs/read_write.c:518 >> >> vfs_write+0x796/0xa30 fs/read_write.c:605 >> >> ksys_write+0x12d/0x250 fs/read_write.c:658 >> >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] >> >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 >> >> entry_SYSCALL_64_after_hwframe+0x44/0xae >> >> >> >>Second to last potentially related work creation: >> >> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 >> >> kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 >> >> insert_work+0x48/0x370 kernel/workqueue.c:1332 >> >> __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 >> >> queue_work_on+0xee/0x110 kernel/workqueue.c:1525 >> >> queue_work include/linux/workqueue.h:507 [inline] >> >> call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 >> >> kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 >> >> kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 >> >> uevent_store+0x42/0x90 drivers/base/bus.c:585 >> >> drv_attr_store+0x6d/0xa0 drivers/base/bus.c:77 >> >> sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 >> >> kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 >> >> call_write_iter include/linux/fs.h:2114 [inline] >> >> new_sync_write+0x426/0x650 fs/read_write.c:518 >> >> vfs_write+0x796/0xa30 fs/read_write.c:605 >> >> ksys_write+0x12d/0x250 fs/read_write.c:658 >> >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] >> >> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 >> >> entry_SYSCALL_64_after_hwframe+0x44/0xae >> >> >> >>The buggy address belongs to the object at ffff88801c86cc00 >> >> which belongs to the cache kmalloc-192 of size 192 >> >>The buggy address is located 28 bytes inside of >> >> 192-byte region [ffff88801c86cc00, ffff88801c86ccc0) >> >>The buggy address belongs to the page: >> >>page:ffffea0000721b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88801c86cc00 pfn:0x1c86c >> >>flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) >> >>raw: 00fff00000000200 ffffea00009f0e48 ffffea00009cd188 ffff888011041a00 >> >>raw: ffff88801c86cc00 000000000010000b 00000001ffffffff 0000000000000000 >> >>page dumped because: kasan: bad access detected >> >>page_owner tracks the page as allocated >> >>page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 7975119940, free_ts 7474437105 >> >> prep_new_page mm/page_alloc.c:2445 [inline] >> >> get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4178 >> >> __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5386 >> >> alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2147 >> >> alloc_pages+0x238/0x2a0 mm/mempolicy.c:2270 >> >> alloc_slab_page mm/slub.c:1702 [inline] >> >> allocate_slab+0x32b/0x4c0 mm/slub.c:1842 >> >> new_slab mm/slub.c:1905 [inline] >> >> new_slab_objects mm/slub.c:2651 [inline] >> >> ___slab_alloc+0x4ba/0x820 mm/slub.c:2814 >> >> __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2854 >> >> slab_alloc_node mm/slub.c:2936 [inline] >> >> slab_alloc mm/slub.c:2978 [inline] >> >> kmem_cache_alloc_trace+0x325/0x3c0 mm/slub.c:2995 >> >> kmalloc include/linux/slab.h:591 [inline] >> >> kzalloc include/linux/slab.h:721 [inline] >> >> call_usermodehelper_setup+0x97/0x340 kernel/umh.c:365 >> >> kobject_uevent_env+0xf73/0x1650 lib/kobject_uevent.c:614 >> >> device_add+0xb71/0x2100 drivers/base/core.c:3305 >> >> register_virtio_device+0x1e1/0x2c0 drivers/virtio/virtio.c:363 >> >> virtio_pci_probe+0x203/0x390 drivers/virtio/virtio_pci_common.c:552 >> >> local_pci_probe+0xdb/0x190 drivers/pci/pci-driver.c:309 >> >> pci_call_probe drivers/pci/pci-driver.c:366 [inline] >> >> __pci_device_probe drivers/pci/pci-driver.c:391 [inline] >> >> pci_device_probe+0x3dd/0x6f0 drivers/pci/pci-driver.c:434 >> >> really_probe+0x291/0xf60 drivers/base/dd.c:576 >> >>page last free stack trace: >> >> reset_page_owner include/linux/page_owner.h:24 [inline] >> >> free_pages_prepare mm/page_alloc.c:1355 [inline] >> >> free_pcp_prepare+0x2c5/0x780 mm/page_alloc.c:1406 >> >> free_unref_page_prepare mm/page_alloc.c:3341 [inline] >> >> free_unref_page+0x19/0x690 mm/page_alloc.c:3420 >> >> __vunmap+0x783/0xb70 mm/vmalloc.c:2569 >> >> free_work+0x58/0x70 mm/vmalloc.c:80 >> >> process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 >> >> worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 >> >> kthread+0x3e5/0x4d0 kernel/kthread.c:319 >> >> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 >> >> >> >>Memory state around the buggy address: >> >> ffff88801c86cb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> >> ffff88801c86cb80: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc >> >>>ffff88801c86cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> >> ^ >> >> ffff88801c86cc80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >> >> ffff88801c86cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> >>================================================================== >> > >> > To fix the uaf, add a couple of changes. Now only for thoughts. >> >> > >> > 1/ s/atomic_add_negative/atomic_inc_not_zero/ to correct the get >> > method. >> >> I really don't think so. The use of atomic_add_negative is very >> deliberate. Changing that fundamentally changes the algorithm into used >> to keep track of things. Definitely not something to lead with. >> >> Before it even makes sense to talk about how to change the code, >> a plausible explanation for how a use after free happens is needed. >> >> That explanation should account for the fact this code was in linux-next >> the since last -rc1 without any kind of issue with the test code. >> >> Did something change in the test infrastructure? Is there another >> bug that is stomping memory and making it look like this code is buggy? >> >> I haven't had a chance to dig in in detail (everyone in my house is >> sick). I am hoping that Alexey Gladkov will have that time soon. > >It's better to look at another report. I think it illustrates >regression better: > >https://syzkaller.appspot.com/bug?id=edc996c68de05701cbd709b1ee99344defb94334 > >Hillf Danton is right about race condition. The situation is rare because >most often alloc_ucounts() and put_ucounts() are executed under rcu lock. >I spent a few days but couldn't reproduce it. > >I did this regression in the b6c336528926 ("Use atomic_t for ucounts >reference counting"). Before to this, the reference count check was under >spin_lock. Now spin_lock in alloc_ucounts() doesn't protect find_ucounts() >from parallel put_ucounts(). > >Atomically increasing the reference count solves the problem between >get_accounts() and put_accounts(), but find_ucounts() is not protected. > >We need to either return spin_lock to the beginning of put_ucounts(), or >recycle alloc_ucounts(). > >> What I can say is that a solution that leads with your code is >> fundamentally misdesigned and everything needs to change, and there >> is no explanation for why it all needs to change is probably not a >> solution to the problem. > >The proposed patch is incorrect because in case of an overflow of the >reference count in find_get_ucounts(), we will get a counter leak. Curious how you will handle the leak without change in the type of count as I failed to work it out within ten minutes without putting the atomic_dec_and_test() in put_ucounts() under ucounts_lock protection. Hillf ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20210720041451.766-1-hdanton@sina.com>]
* Re: [syzbot] KASAN: use-after-free Write in put_ucounts [not found] ` <20210720041451.766-1-hdanton@sina.com> @ 2021-07-20 16:29 ` Eric W. Biederman 0 siblings, 0 replies; 8+ messages in thread From: Eric W. Biederman @ 2021-07-20 16:29 UTC (permalink / raw) To: Hillf Danton; +Cc: syzbot, legion, linux-kernel, syzkaller-bugs Hillf Danton <hdanton@sina.com> writes: > On Mon, 19 Jul 2021 12:24:41 -0500 Eric W. Biederman wrote: >>> >>> To fix the uaf, add a couple of changes. Now only for thoughts. >>> >>> 1/ s/atomic_add_negative/atomic_inc_not_zero/ to correct the get >>> method. >> >>I really don't think so. The use of atomic_add_negative is very >>deliberate. Changing that fundamentally changes the algorithm into used > > Given atomic_dec_and_test() in put_ucounts(), what sense are you > deliberately trying to make by bumping up a zero count? > >>to keep track of things. Definitely not something to lead with. >> >>Before it even makes sense to talk about how to change the code, >>a plausible explanation for how a use after free happens is needed. > > I am trying just to avoid touching zero count. That is it. Observing a zero-reference count in this case is a result of a use-after-free. So that is definitely not what needs to be fixed. >>That explanation should account for the fact this code was in linux-next >>the since last -rc1 without any kind of issue with the test code. > > The code is no good without surviving syzbot, right? And -rcX does not > matter. That was with syzbot running against linux-next for 8ish weeks. Something changed that syzbot is now reporting an error. It is definitely worth fixing but we need to track down and understand what the bug is. Eric ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v1] ucounts: Fix race condition between alloc_ucounts and put_ucounts 2021-07-17 6:22 [syzbot] KASAN: use-after-free Write in put_ucounts syzbot [not found] ` <20210719094432.425-1-hdanton@sina.com> @ 2021-07-27 15:24 ` Alexey Gladkov [not found] ` <20210728025837.1641-1-hdanton@sina.com> 2 siblings, 0 replies; 8+ messages in thread From: Alexey Gladkov @ 2021-07-27 15:24 UTC (permalink / raw) To: LKML Cc: syzbot+01985d7909f9468f013c, syzbot+59dd63761094a80ad06d, syzbot+6cd79f45bb8fa1c9eeae, syzbot+b6e65bd125a05f803d6b, Eric W. Biederman, Hillf Danton The race happens because put_ucounts() doesn't use spinlock and get_ucounts is not under spinlock: CPU0 CPU1 ---- ---- alloc_ucounts() put_ucounts() spin_lock_irq(&ucounts_lock); ucounts = find_ucounts(ns, uid, hashent); atomic_dec_and_test(&ucounts->count)) spin_unlock_irq(&ucounts_lock); spin_lock_irqsave(&ucounts_lock, flags); hlist_del_init(&ucounts->node); spin_unlock_irqrestore(&ucounts_lock, flags); kfree(ucounts); ucounts = get_ucounts(ucounts); ================================================================== BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:101 [inline] BUG: KASAN: use-after-free in atomic_add_negative include/asm-generic/atomic-instrumented.h:556 [inline] BUG: KASAN: use-after-free in get_ucounts kernel/ucount.c:152 [inline] BUG: KASAN: use-after-free in get_ucounts kernel/ucount.c:150 [inline] BUG: KASAN: use-after-free in alloc_ucounts+0x19b/0x5b0 kernel/ucount.c:188 Write of size 4 at addr ffff88802821e41c by task syz-executor.4/16785 CPU: 1 PID: 16785 Comm: syz-executor.4 Not tainted 5.14.0-rc1-next-20210712-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105 print_address_description.constprop.0.cold+0x6c/0x309 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:436 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:101 [inline] atomic_add_negative include/asm-generic/atomic-instrumented.h:556 [inline] get_ucounts kernel/ucount.c:152 [inline] get_ucounts kernel/ucount.c:150 [inline] alloc_ucounts+0x19b/0x5b0 kernel/ucount.c:188 set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684 __sys_setuid+0x285/0x400 kernel/sys.c:623 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde54097188 EFLAGS: 00000246 ORIG_RAX: 0000000000000069 RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 00000000004665d9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000000ff RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80 R13: 00007ffc8655740f R14: 00007fde54097300 R15: 0000000000022000 Allocated by task 16784: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] ____kasan_kmalloc mm/kasan/common.c:513 [inline] ____kasan_kmalloc mm/kasan/common.c:472 [inline] __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:522 kmalloc include/linux/slab.h:591 [inline] kzalloc include/linux/slab.h:721 [inline] alloc_ucounts+0x23d/0x5b0 kernel/ucount.c:169 set_cred_ucounts+0x171/0x3a0 kernel/cred.c:684 __sys_setuid+0x285/0x400 kernel/sys.c:623 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 16785: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:360 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free mm/kasan/common.c:328 [inline] __kasan_slab_free+0xfb/0x130 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:229 [inline] slab_free_hook mm/slub.c:1650 [inline] slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1675 slab_free mm/slub.c:3235 [inline] kfree+0xeb/0x650 mm/slub.c:4295 put_ucounts kernel/ucount.c:200 [inline] put_ucounts+0x117/0x150 kernel/ucount.c:192 put_cred_rcu+0x27a/0x520 kernel/cred.c:124 rcu_do_batch kernel/rcu/tree.c:2550 [inline] rcu_core+0x7ab/0x1380 kernel/rcu/tree.c:2785 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 Last potentially related work creation: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 insert_work+0x48/0x370 kernel/workqueue.c:1332 __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 queue_work_on+0xee/0x110 kernel/workqueue.c:1525 queue_work include/linux/workqueue.h:507 [inline] call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 netdev_queue_add_kobject net/core/net-sysfs.c:1621 [inline] netdev_queue_update_kobjects+0x374/0x450 net/core/net-sysfs.c:1655 register_queue_kobjects net/core/net-sysfs.c:1716 [inline] netdev_register_kobject+0x35a/0x430 net/core/net-sysfs.c:1959 register_netdevice+0xd33/0x1500 net/core/dev.c:10331 nsim_init_netdevsim drivers/net/netdevsim/netdev.c:317 [inline] nsim_create+0x381/0x4d0 drivers/net/netdevsim/netdev.c:364 __nsim_dev_port_add+0x32e/0x830 drivers/net/netdevsim/dev.c:1295 nsim_dev_port_add_all+0x53/0x150 drivers/net/netdevsim/dev.c:1355 nsim_dev_probe+0xcb5/0x1190 drivers/net/netdevsim/dev.c:1496 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3356 nsim_bus_dev_new drivers/net/netdevsim/bus.c:431 [inline] new_device_store+0x436/0x710 drivers/net/netdevsim/bus.c:298 bus_attr_store+0x72/0xa0 drivers/base/bus.c:122 sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2152 [inline] new_sync_write+0x426/0x650 fs/read_write.c:518 vfs_write+0x75a/0xa40 fs/read_write.c:605 ksys_write+0x12d/0x250 fs/read_write.c:658 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Second to last potentially related work creation: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:348 insert_work+0x48/0x370 kernel/workqueue.c:1332 __queue_work+0x5c1/0xed0 kernel/workqueue.c:1498 queue_work_on+0xee/0x110 kernel/workqueue.c:1525 queue_work include/linux/workqueue.h:507 [inline] call_usermodehelper_exec+0x1f0/0x4c0 kernel/umh.c:435 kobject_uevent_env+0xf8f/0x1650 lib/kobject_uevent.c:618 kobject_synth_uevent+0x701/0x850 lib/kobject_uevent.c:208 uevent_store+0x20/0x50 drivers/base/core.c:2371 dev_attr_store+0x50/0x80 drivers/base/core.c:2072 sysfs_kf_write+0x110/0x160 fs/sysfs/file.c:139 kernfs_fop_write_iter+0x342/0x500 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2152 [inline] new_sync_write+0x426/0x650 fs/read_write.c:518 vfs_write+0x75a/0xa40 fs/read_write.c:605 ksys_write+0x12d/0x250 fs/read_write.c:658 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88802821e400 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 28 bytes inside of 192-byte region [ffff88802821e400, ffff88802821e4c0) The buggy address belongs to the page: page:ffffea0000a08780 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2821e flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000200 dead000000000100 dead000000000122 ffff888010841a00 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 12874702440, free_ts 12637793385 prep_new_page mm/page_alloc.c:2433 [inline] get_page_from_freelist+0xa72/0x2f80 mm/page_alloc.c:4166 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5374 alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2119 alloc_pages+0x238/0x2a0 mm/mempolicy.c:2242 alloc_slab_page mm/slub.c:1713 [inline] allocate_slab+0x32b/0x4c0 mm/slub.c:1853 new_slab mm/slub.c:1916 [inline] new_slab_objects mm/slub.c:2662 [inline] ___slab_alloc+0x4ba/0x820 mm/slub.c:2825 __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2865 slab_alloc_node mm/slub.c:2947 [inline] slab_alloc mm/slub.c:2989 [inline] __kmalloc+0x312/0x330 mm/slub.c:4133 kmalloc include/linux/slab.h:596 [inline] kzalloc include/linux/slab.h:721 [inline] __register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1318 rds_tcp_init_net+0x1db/0x4f0 net/rds/tcp.c:551 ops_init+0xaf/0x470 net/core/net_namespace.c:140 __register_pernet_operations net/core/net_namespace.c:1137 [inline] register_pernet_operations+0x35a/0x850 net/core/net_namespace.c:1214 register_pernet_device+0x26/0x70 net/core/net_namespace.c:1301 rds_tcp_init+0x77/0xe0 net/rds/tcp.c:717 do_one_initcall+0x103/0x650 init/main.c:1285 do_initcall_level init/main.c:1360 [inline] do_initcalls init/main.c:1376 [inline] do_basic_setup init/main.c:1396 [inline] kernel_init_freeable+0x6b8/0x741 init/main.c:1598 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1343 [inline] free_pcp_prepare+0x312/0x7d0 mm/page_alloc.c:1394 free_unref_page_prepare mm/page_alloc.c:3329 [inline] free_unref_page+0x19/0x690 mm/page_alloc.c:3408 __vunmap+0x783/0xb70 mm/vmalloc.c:2587 free_work+0x58/0x70 mm/vmalloc.c:82 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 kthread+0x3e5/0x4d0 kernel/kthread.c:319 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Memory state around the buggy address: ffff88802821e300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88802821e380: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc >ffff88802821e400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88802821e480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88802821e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Reported-by: syzbot+01985d7909f9468f013c@syzkaller.appspotmail.com Reported-by: syzbot+59dd63761094a80ad06d@syzkaller.appspotmail.com Reported-by: syzbot+6cd79f45bb8fa1c9eeae@syzkaller.appspotmail.com Reported-by: syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com Fixes: b6c336528926 ("Use atomic_t for ucounts reference counting") Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Hillf Danton <hdanton@sina.com> Signed-off-by: Alexey Gladkov <legion@kernel.org> --- kernel/ucount.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/kernel/ucount.c b/kernel/ucount.c index 87799e2379bd..77be3bbe3cc4 100644 --- a/kernel/ucount.c +++ b/kernel/ucount.c @@ -160,6 +160,7 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) { struct hlist_head *hashent = ucounts_hashentry(ns, uid); struct ucounts *ucounts, *new; + long overflow; spin_lock_irq(&ucounts_lock); ucounts = find_ucounts(ns, uid, hashent); @@ -184,8 +185,12 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) return new; } } + overflow = atomic_add_negative(1, &ucounts->count); spin_unlock_irq(&ucounts_lock); - ucounts = get_ucounts(ucounts); + if (overflow) { + put_ucounts(ucounts); + return NULL; + } return ucounts; } @@ -193,8 +198,7 @@ void put_ucounts(struct ucounts *ucounts) { unsigned long flags; - if (atomic_dec_and_test(&ucounts->count)) { - spin_lock_irqsave(&ucounts_lock, flags); + if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) { hlist_del_init(&ucounts->node); spin_unlock_irqrestore(&ucounts_lock, flags); kfree(ucounts); -- 2.29.3 ^ permalink raw reply related [flat|nested] 8+ messages in thread
[parent not found: <20210728025837.1641-1-hdanton@sina.com>]
* Re: [PATCH v1] ucounts: Fix race condition between alloc_ucounts and put_ucounts [not found] ` <20210728025837.1641-1-hdanton@sina.com> @ 2021-07-28 12:24 ` Alexey Gladkov 2021-07-28 17:05 ` Eric W. Biederman 0 siblings, 1 reply; 8+ messages in thread From: Alexey Gladkov @ 2021-07-28 12:24 UTC (permalink / raw) To: Hillf Danton Cc: LKML, syzbot+01985d7909f9468f013c, syzbot+59dd63761094a80ad06d, syzbot+6cd79f45bb8fa1c9eeae, syzbot+b6e65bd125a05f803d6b, Eric W. Biederman On Wed, Jul 28, 2021 at 10:58:37AM +0800, Hillf Danton wrote: > On Tue, 27 Jul 2021 17:24:18 +0200 Alexey Gladkov wrote: > > +++ b/kernel/ucount.c > > @@ -160,6 +160,7 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) > > { > > struct hlist_head *hashent = ucounts_hashentry(ns, uid); > > struct ucounts *ucounts, *new; > > + long overflow; > > > > spin_lock_irq(&ucounts_lock); > > ucounts = find_ucounts(ns, uid, hashent); > > @@ -184,8 +185,12 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) > > return new; > > } > > } > > + overflow = atomic_add_negative(1, &ucounts->count); > > spin_unlock_irq(&ucounts_lock); > > - ucounts = get_ucounts(ucounts); > > + if (overflow) { > > + put_ucounts(ucounts); > > Given if (atomic_add_unless(atomic, -1, 1)) > return 0; > > put can not help roll back overflow. In case of overflow, we don't try to rollback overflow. We return an error. > BTW can you specify a bit on the real workloads with the risk of count overflow? For example, one user has too many processes in one namespace. It is necessary to check and handle the possibility of counter overflow in this case. Linus described it here: https://lore.kernel.org/lkml/CAHk-%3dwjYOCgM%2bmKzwTZwkDDg12DdYjFFkmoFKYLim7NFmR9HBg@mail.gmail.com/ > > + return NULL; > > + } > > return ucounts; > > } > > > > @@ -193,8 +198,7 @@ void put_ucounts(struct ucounts *ucounts) > > { > > unsigned long flags; > > > > - if (atomic_dec_and_test(&ucounts->count)) { > > - spin_lock_irqsave(&ucounts_lock, flags); > > + if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) { > > hlist_del_init(&ucounts->node); > > spin_unlock_irqrestore(&ucounts_lock, flags); > > kfree(ucounts); > > -- > > 2.29.3 > -- Rgrds, legion ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1] ucounts: Fix race condition between alloc_ucounts and put_ucounts 2021-07-28 12:24 ` Alexey Gladkov @ 2021-07-28 17:05 ` Eric W. Biederman 0 siblings, 0 replies; 8+ messages in thread From: Eric W. Biederman @ 2021-07-28 17:05 UTC (permalink / raw) To: Alexey Gladkov Cc: Hillf Danton, LKML, syzbot+01985d7909f9468f013c, syzbot+59dd63761094a80ad06d, syzbot+6cd79f45bb8fa1c9eeae, syzbot+b6e65bd125a05f803d6b Alexey Gladkov <legion@kernel.org> writes: > On Wed, Jul 28, 2021 at 10:58:37AM +0800, Hillf Danton wrote: >> On Tue, 27 Jul 2021 17:24:18 +0200 Alexey Gladkov wrote: >> > +++ b/kernel/ucount.c >> > @@ -160,6 +160,7 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) >> > { >> > struct hlist_head *hashent = ucounts_hashentry(ns, uid); >> > struct ucounts *ucounts, *new; >> > + long overflow; >> > >> > spin_lock_irq(&ucounts_lock); >> > ucounts = find_ucounts(ns, uid, hashent); >> > @@ -184,8 +185,12 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid) >> > return new; >> > } >> > } >> > + overflow = atomic_add_negative(1, &ucounts->count); >> > spin_unlock_irq(&ucounts_lock); >> > - ucounts = get_ucounts(ucounts); >> > + if (overflow) { >> > + put_ucounts(ucounts); >> >> Given if (atomic_add_unless(atomic, -1, 1)) >> return 0; >> >> put can not help roll back overflow. > > In case of overflow, we don't try to rollback overflow. We return an > error. Unfortunately I don't see the email with the original comment, but let me see if I can clarify a little. The code in get_ucounts explicitly uses atomic_add_negative as a performance optimization. Which means just by testing the negative status of the count it is easy to tell if the count is larger than is supported. Where this matters is that atomic_add_negative can be cheaper than cmpxchg. Which means it is faster to reserve all of the negative numbers to catch the case where the counter grows too large, then to precisely bound the count at a specific cut off. This particular code path can not use atomic_add_unless(.., -1,...) get_ucounts may have already hit the limit so it may be a negative value other than -1. >> BTW can you specify a bit on the real workloads with the risk of count overflow? One place where I think it is possible to reach a count of 2^31 is to set the rlimit for pending signals to unlimited and post a bunch of realtime signals to a process which simply does not read them. As pointed out in Alex's link below this code notices when the maximum count is reached and fails gracefully unlike refcount_t which would leak memory. The point is to handle unrealistic workloads gracefully from a reference counting perspective. If real workloads start reaching the maximum count something probably needs to change. (larger counts or changing what gets counted). > For example, one user has too many processes in one namespace. > > It is necessary to check and handle the possibility of counter overflow > in this case. Linus described it here: > > https://lore.kernel.org/lkml/CAHk-%3dwjYOCgM%2bmKzwTZwkDDg12DdYjFFkmoFKYLim7NFmR9HBg@mail.gmail.com/ > >> > + return NULL; >> > + } >> > return ucounts; >> > } >> > >> > @@ -193,8 +198,7 @@ void put_ucounts(struct ucounts *ucounts) >> > { >> > unsigned long flags; >> > >> > - if (atomic_dec_and_test(&ucounts->count)) { >> > - spin_lock_irqsave(&ucounts_lock, flags); >> > + if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) { >> > hlist_del_init(&ucounts->node); >> > spin_unlock_irqrestore(&ucounts_lock, flags); >> > kfree(ucounts); >> > -- >> > 2.29.3 Eric ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-28 17:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-17 6:22 [syzbot] KASAN: use-after-free Write in put_ucounts syzbot
[not found] ` <20210719094432.425-1-hdanton@sina.com>
2021-07-19 17:24 ` Eric W. Biederman
2021-07-24 17:57 ` Alexey Gladkov
2021-07-25 0:32 ` Hillf Danton
[not found] ` <20210720041451.766-1-hdanton@sina.com>
2021-07-20 16:29 ` Eric W. Biederman
2021-07-27 15:24 ` [PATCH v1] ucounts: Fix race condition between alloc_ucounts and put_ucounts Alexey Gladkov
[not found] ` <20210728025837.1641-1-hdanton@sina.com>
2021-07-28 12:24 ` Alexey Gladkov
2021-07-28 17:05 ` Eric W. Biederman
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.