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 <[email protected]>
Best Regards,
Yue
Since tomoyo_write_control() updates head->write_buf when write() of long
lines is requested, we need to fetch head->write_buf after head->io_sem is
held. Otherwise, concurrent write() requests can cause use-after-free-write
and double-free problems.
Reported-by: Sam Sun <[email protected]>
Closes: https://lkml.kernel.org/r/CAEkJfYNDspuGxYx5kym8Lvp--D36CMDUErg4rxfWFJuPbbji8g@mail.gmail.com
Fixes: bd03a3e4c9a9 ("TOMOYO: Add policy namespace support.")
Cc: [email protected] # Linux 3.1+
Signed-off-by: Tetsuo Handa <[email protected]>
---
I couldn't reproduce this problem in my environment, but I believe
this does fix a bug. Linus, can you directly apply to linux.git ?
If Linus wants a GIT PULL request, can Paul send this patch via LSM tree
because TOMOYO's git tree is not working?
security/tomoyo/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
index 57ee70ae50f2..ea3140d510ec 100644
--- a/security/tomoyo/common.c
+++ b/security/tomoyo/common.c
@@ -2649,13 +2649,14 @@ ssize_t tomoyo_write_control(struct tomoyo_io_buffer *head,
{
int error = buffer_len;
size_t avail_len = buffer_len;
- char *cp0 = head->write_buf;
+ char *cp0;
int idx;
if (!head->write)
return -EINVAL;
if (mutex_lock_interruptible(&head->io_sem))
return -EINTR;
+ cp0 = head->write_buf;
head->read_user_buf_avail = 0;
idx = tomoyo_read_lock();
/* Read a line and dispatch it to the policy handler. */
--
2.34.1
On Fri, 1 Mar 2024 at 05:04, Tetsuo Handa
<[email protected]> wrote:
>
> I couldn't reproduce this problem in my environment, but I believe
> this does fix a bug. Linus, can you directly apply to linux.git ?
Thanks. Applied,
Linus