Received-SPF: pass (google.com: domain of linux-kernel+bounces-95051-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
From: =?UTF-8?B?5YiY6YCa?= <lyutoon@gmail.com>
Date: Thu, 7 Mar 2024 15:23:46 +0800
Message-ID: <CAEJPjCvT3Uag-pMTYuigEjWZHn1sGMZ0GCjVVCv29tNHK76Cgg@mail.gmail.com>
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)
To: leah.rumancik@gmail.com, djwong@kernel.org, linux-xfs@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

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