[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEJPjCvT3Uag-pMTYuigEjWZHn1sGMZ0GCjVVCv29tNHK76Cgg@mail.gmail.com>
Date: Thu, 7 Mar 2024 15:23:46 +0800
From: 刘通 <lyutoon@...il.com>
To: leah.rumancik@...il.com, djwong@...nel.org, linux-xfs@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: A bug was found in Linux Kernel 5.15.148 and 5.15.150: KASAN:
use-after-free in xfs_allocbt_init_key_from_rec (with POC)
Hi upstream community,
I was fuzzing a LTS version of Linux kernel 5.15.148 with my modified
syzkaller and I found a bug named "KASAN: use-after-free in
xfs_allocbt_init_key_from_rec".
I tested the PoC on 5.15.148, 5.15.149 and 5.15.150 with sanitizer on
and found sanitizer through a panic as "KASAN: use-after-free in
xfs_allocbt_init_key_from_rec" on 5.15.148 and 5.15.150, but there was
no panic and sanitizer error in 5.15.149.
The syzkaller log, report, kernel config, PoC can be found here:
https://drive.google.com/file/d/1w6VKKewt4VQzb9FzcGtkELJUOwd1wMcC/view?usp=sharing
# Analysis (rough):
Because that I cannot understand the report0 clearly in the zip file
above, so I rerun the PoC on my vm (5.15.148) and I get another report
named as the same but it looks much clearer than the report0. The new
report can be found in:
https://drive.google.com/file/d/1Vg_4Qwueow6VgjLrijnUB8QbZVx902sv/view?usp=sharing
In this report, we can easily see that the memory allocation and free:
Allocation:
```
[ 62.995194][ T6349] Allocated by task 6343:
[ 62.995610][ T6349] kasan_save_stack+0x1b/0x40
[ 62.996044][ T6349] __kasan_slab_alloc+0x61/0x80
[ 62.996475][ T6349] kmem_cache_alloc+0x18e/0x6b0
[ 62.996918][ T6349] getname_flags+0xd2/0x5b0
[ 62.997335][ T6349] user_path_at_empty+0x2b/0x60
[ 62.997782][ T6349] vfs_statx+0x13c/0x370
[ 62.998193][ T6349] __do_sys_newlstat+0x91/0x110
[ 62.998634][ T6349] do_syscall_64+0x35/0xb0
[ 62.999033][ T6349] entry_SYSCALL_64_after_hwframe+0x61/0xcb
```
Free:
```
[ 62.999776][ T6349] Freed by task 6343:
[ 63.000135][ T6349] kasan_save_stack+0x1b/0x40
[ 63.000555][ T6349] kasan_set_track+0x1c/0x30
[ 63.001053][ T6349] kasan_set_free_info+0x20/0x30
[ 63.001638][ T6349] __kasan_slab_free+0xe1/0x110
[ 63.002206][ T6349] kmem_cache_free+0x82/0x5b0
[ 63.002742][ T6349] putname+0xfe/0x140
[ 63.003103][ T6349] user_path_at_empty+0x4d/0x60
[ 63.003551][ T6349] vfs_statx+0x13c/0x370
[ 63.003943][ T6349] __do_sys_newlstat+0x91/0x110
[ 63.004378][ T6349] do_syscall_64+0x35/0xb0
[ 63.004841][ T6349] entry_SYSCALL_64_after_hwframe+0x61/0xcb
```
So this is a use-after-free bug: allocated by `kmem_cache_alloc` and
freed by `kmem_cache_free`.
And according to the report, the UAF occurs in
`xfs_allocbt_init_key_from_rec`, `key->alloc.ar_startblock =
rec->alloc.ar_startblock;` which indicates that maybe
`rec->alloc.ar_startblock` was freed before.
# Step to reproduce:
1. download the zip file
2. unzip it
3. compile the kernel (5.15.148, 5.15.150) with kernel_config
4. start the kernel with qemu vm
5. scp repro.c to the vm
6. compile the repro.c and run it: gcc repro.c -o exp && ./exp
7. you will see the KASAN error
# Note:
I didn't find any related reports on the internet, which indicates
that it may be a 0day. Hope the upstream can help check and fix it.
And I'll be happy to provide more information if needed.
Best,
Tong
Powered by blists - more mailing lists