On 4/2/24 5:08 AM, 刘通 wrote: > Hi Eric. > > I've actually always followed this principle of vulnerability analysis > that you mentioned, but in this case, due to my lack of familiarity > with xfs, I wasn't able to construct a sensible PoC. I try to do my > best to analyze the root cause when it's in my power to do so, but I > couldn't do it in this case. Ok, but the things I suggested below don't require deep knowledge of xfs - just looking at the POC and understanding/describing what it is doing, simplifying it to the fewest syscalls to provoke the problem, what privileges are required to form a general assessment of a possible threat, etc. > I'm sorry for adding to your workload, > but I don't think that this is an indication that it's a false > positive, KASAN's memory detection is justified, so are you 100% sure > that the program you constructed is completely correct? I mean, KASAN > reported a uaf vulnerability, which is not unfounded. If you are able > to reproduce the crash as I said before, then it is a fact that it > exists with a high probability, but if when you constructed the > simplified program, is it completely consistent with the original > repro.c? I did not construct a new reproducer, I ran your exact set of steps using your kernel version, your config, and your repro.c, and while it triggered a bug in XFS, it did not trigger any KASAN errors. As I originally asked - does it do so for you? Looking at the logs, it seems very possible that tests that ran prior to the xfs test may have corrupted memory, which the xfs repro.c stumbled into during your run, and won't be reproduced on a fresh run of that reproducer. Thanks, -Eric > Best, > Tong > > Eric Sandeen <sandeen@xxxxxxxxxxx> 于2024年4月2日周二 13:54写道： >> >> On 3/7/24 1:23 AM, 刘通 wrote: >>> 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: >> >> As a PhD student interested in security analysis, you could do much more >> here. >> >> For starters, test this on an upstream/mainline kernel to see if it >> reproduces. >> >> Provide the filesystem image that seems to reproduce it, rather than >> an array in a C file. >> >> Look at your reproducer, and identify the ioctls and syscalls that you >> believe provoked the error. See what privileges are needed to invoke them, >> if you believe this may be a security flaw. >> >> Test your reproducer in isolation, and see if it actually reproduces your >> use after free (I don't think that it does.) >> >> If it doesn't, look back at the tests that ran before it, and see if >> something is corrupting memory, etc. >> >> It's far too easy for someone to turn a syzkaller crank, throw it over >> the wall, and move on. If you want to help, dig in, don't just pawn off >> the problem with no effort to investigate what you believe you've found. >> >>> ``` >>> [ 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 >> >> AFAICT you won't. I did exactly this, and got no KASAN error. >> Did you, after following these steps on a fresh boot of the kernel? >> >> -Eric >> >>> # 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 >>> >> >
