[Linux Kernel Bug] KASAN: slab-out-of-bounds Write in tomoyo_write_control

Fri Mar 1 08:32:44 UTC 2024

Dear developers and maintainers,

We found a slab-out-of-bounds bug in Linux kernel through
modified Syzkaller. Kernel commit is b401b621758, Linux
6.8-rc5. Kernel config and C repro is attached to this email.

KASAN report is listed below.
```
==================================================================
BUG: KASAN: slab-out-of-bounds in tomoyo_write_control+0x10cd/0x1310
security/tomoyo/common.c:2685
Write of size 1 at addr ffff88811277fc2e by task syz-executor287/8111

CPU: 0 PID: 8111 Comm: syz-executor287 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc1/0x5e0 mm/kasan/report.c:475
 kasan_report+0xbe/0xf0 mm/kasan/report.c:588
 tomoyo_write_control+0x10cd/0x1310 security/tomoyo/common.c:2685
 do_loop_readv_writev fs/read_write.c:758 [inline]
 do_loop_readv_writev fs/read_write.c:743 [inline]
 do_iter_write+0x556/0x7d0 fs/read_write.c:862
 vfs_writev+0x1dd/0x6c0 fs/read_write.c:933
 do_pwritev fs/read_write.c:1030 [inline]
 __do_sys_pwritev fs/read_write.c:1077 [inline]
 __se_sys_pwritev fs/read_write.c:1072 [inline]
 __x64_sys_pwritev+0x226/0x300 fs/read_write.c:1072
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fd021d334ed
Code: c3 e8 37 20 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd021cbc1b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000128
RAX: ffffffffffffffda RBX: 00007fd021dcf218 RCX: 00007fd021d334ed
RDX: 0000000000000004 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 00007fd021dcf210 R08: 0000000000000008 R09: 00007fd021cbc640
R10: 00000000fffff552 R11: 0000000000000246 R12: 00007fd021d99078
R13: 000000000000006e R14: 00007fd021cfb5f0 R15: 00007fd021c9c000
 </TASK>

Allocated by task 1:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 ____kasan_kmalloc mm/kasan/common.c:333 [inline]
 __kasan_kmalloc+0xa3/0xb0 mm/kasan/common.c:383
 kasan_kmalloc include/linux/kasan.h:198 [inline]
 __do_kmalloc_node mm/slab_common.c:1007 [inline]
 __kmalloc+0x5d/0xd0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 tomoyo_realpath_from_path+0xc3/0x600 security/tomoyo/realpath.c:251
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_number_perm+0x21c/0x550 security/tomoyo/file.c:723
 security_file_ioctl+0x54/0xb0 security/security.c:2647
 __do_sys_ioctl fs/ioctl.c:865 [inline]
 __se_sys_ioctl fs/ioctl.c:857 [inline]
 __x64_sys_ioctl+0xb7/0x210 fs/ioctl.c:857
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Freed by task 1:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x28/0x40 mm/kasan/generic.c:522
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free+0x134/0x190 mm/kasan/common.c:200
 kasan_slab_free include/linux/kasan.h:164 [inline]
 __cache_free mm/slab.c:3370 [inline]
 __do_kmem_cache_free mm/slab.c:3557 [inline]
 __kmem_cache_free+0xcd/0x3c0 mm/slab.c:3564
 tomoyo_realpath_from_path+0x190/0x600 security/tomoyo/realpath.c:286
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_number_perm+0x21c/0x550 security/tomoyo/file.c:723
 security_file_ioctl+0x54/0xb0 security/security.c:2647
 __do_sys_ioctl fs/ioctl.c:865 [inline]
 __se_sys_ioctl fs/ioctl.c:857 [inline]
 __x64_sys_ioctl+0xb7/0x210 fs/ioctl.c:857
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

The buggy address belongs to the object at ffff88811277e000
 which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 3118 bytes to the right of
 allocated 4096-byte region [ffff88811277e000, ffff88811277f000)

The buggy address belongs to the physical page:
page:ffffea000449df80 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x11277e
head:ffffea000449df80 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x57ff00000000840(slab|head|node=1|zone=2|lastcpupid=0x7ff)
page_type: 0x1()
raw: 057ff00000000840 ffff888013040900 ffffea00044f4390 ffffea000448c890
raw: 0000000000000000 ffff88811277e000 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask
0x242040(__GFP_IO|__GFP_NOWARN|__GFP_COMP|__GFP_THISNODE), pid 1, tgid
1 (systemd), ts 105574054481, free_ts 105561505627
 set_page_owner include/linux/page_owner.h:31 [inline]
 post_alloc_hook+0x2d9/0x350 mm/page_alloc.c:1537
 prep_new_page mm/page_alloc.c:1544 [inline]
 get_page_from_freelist+0xd38/0x2fa0 mm/page_alloc.c:3312
 __alloc_pages+0x21d/0x21f0 mm/page_alloc.c:4568
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 kmem_getpages mm/slab.c:1356 [inline]
 cache_grow_begin+0x9b/0x3c0 mm/slab.c:2550
 cache_alloc_refill+0x289/0x3a0 mm/slab.c:2923
 ____cache_alloc mm/slab.c:2999 [inline]
 ____cache_alloc mm/slab.c:2982 [inline]
 __do_cache_alloc mm/slab.c:3182 [inline]
 slab_alloc_node mm/slab.c:3230 [inline]
 __kmem_cache_alloc_node+0x39f/0x420 mm/slab.c:3521
 __do_kmalloc_node mm/slab_common.c:1006 [inline]
 __kmalloc+0x4d/0xd0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 tomoyo_realpath_from_path+0xc3/0x600 security/tomoyo/realpath.c:251
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_number_perm+0x21c/0x550 security/tomoyo/file.c:723
 security_file_ioctl+0x54/0xb0 security/security.c:2647
 __do_sys_ioctl fs/ioctl.c:865 [inline]
 __se_sys_ioctl fs/ioctl.c:857 [inline]
 __x64_sys_ioctl+0xb7/0x210 fs/ioctl.c:857
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1137 [inline]
 free_unref_page_prepare+0x4c5/0xa60 mm/page_alloc.c:2347
 free_unref_page+0x33/0x3d0 mm/page_alloc.c:2487
 slab_destroy mm/slab.c:1608 [inline]
 slabs_destroy+0x85/0xc0 mm/slab.c:1628
 cache_flusharray mm/slab.c:3341 [inline]
 ___cache_free+0x2c5/0x410 mm/slab.c:3404
 qlink_free mm/kasan/quarantine.c:168 [inline]
 qlist_free_all+0x4f/0x1a0 mm/kasan/quarantine.c:187
 kasan_quarantine_reduce+0x18e/0x1d0 mm/kasan/quarantine.c:294
 __kasan_slab_alloc+0x63/0x90 mm/kasan/common.c:305
 kasan_slab_alloc include/linux/kasan.h:188 [inline]
 slab_post_alloc_hook mm/slab.h:763 [inline]
 slab_alloc_node mm/slab.c:3237 [inline]
 slab_alloc mm/slab.c:3246 [inline]
 __kmem_cache_alloc_lru mm/slab.c:3423 [inline]
 kmem_cache_alloc+0x2aa/0x370 mm/slab.c:3432
 getname_flags.part.0+0x50/0x4f0 fs/namei.c:140
 getname_flags+0x9e/0xe0 include/linux/audit.h:321
 vfs_fstatat+0x9a/0x150 fs/stat.c:298
 __do_sys_newfstatat+0x8a/0x110 fs/stat.c:463
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Memory state around the buggy address:
 ffff88811277fb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88811277fb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88811277fc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                  ^
 ffff88811277fc80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88811277fd00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
```
We analyzed cause of this bug. In function "tomoyo_write_control", if more than
one thread enter while loop in line 2662 (while (avail_len > 0)), the
kfree in line 2674
could affect other thread using pointer cp0 (like in line 2685,
cp0[head->w.avail++]),
causing concurrent UAF.
If you have any questions, please contact us.
Reported by Yue Sun <samsun1006219 at gmail.com>

Best Regards,
Yue