[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG_fn=VuMZQH1yFxFZ=n1+3d-ndywMPYwzd139k4hWevVkaB_Q@mail.gmail.com>
Date: Wed, 21 May 2025 14:04:52 +0200
From: Alexander Potapenko <glider@...gle.com>
To: "huk23@...udan.edu.cn" <huk23@...udan.edu.cn>
Cc: Dave Kleikamp <shaggy@...nel.org>, syzkaller <syzkaller@...glegroups.com>,
linux-kernel <linux-kernel@...r.kernel.org>, Jiaji Qin <jjtan24@...udan.edu.cn>,
Shuoran Bai <baishuoran@...eu.edu.cn>
Subject: Re: KASAN: slab-use-after-free Write in diWrite
On Wed, May 21, 2025 at 12:24 PM 'huk23@...udan.edu.cn' via syzkaller
<syzkaller@...glegroups.com> wrote:
>
> Dear Maintainers,
>
>
>
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (101th)was triggered.
Have you tried to look up this report in the LKML archive or in
https://groups.google.com/g/syzkaller-bugs, where all
syzkaller-reported bugs are sent?
https://groups.google.com/g/syzkaller-bugs/c/kPwF_ow20LQ/m/pN-_ZqVDDAAJ
is clearly the same bug.
According to the dashboard link
(https://syzkaller.appspot.com/bug?extid=aa6df9d3b383bf5f047f), it is
still occurring, why report it again?
>
> HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
> git tree: upstream
> Output:https:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/101_KASAN%3A%20slab-use-after-free%20Write%20in%20diWrite/101report.txt
> Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/config.txt
> C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/101_KASAN%3A%20slab-use-after-free%20Write%20in%20diWrite/101repro.c
> Syzlang reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/101_KASAN%3A%20slab-use-after-free%20Write%20in%20diWrite/101repro.txt
>
>
>
> This is a slab-use-after-free bug in the JFS filesystem driver, inside the diWrite function. When JFS is mounted over loop device and the backend storage of that loop device is changed via the LOOP_SET_FD ioctl, JFS may not correctly invalidate its internal cache.
> triggering procedure: JFS filesystem is mounted over a loop device. The backend file of that loop device is changed and operations (such as jfs_readdir triggered by the getents64 system call here, which further calls txCommit and diWrite) on the JFS filesystem try to write back inode data. The diWrite function tries to write a memory address that it thinks is still valid, but that address belongs to a slab object that has been freed (by some ext4 related operations) and possibly reallocated.
Is this text LLM-generated?
>
> We have reproduced this issue several times on 6.15-rc6 again.
>
>
> This is the URL of the 2024 syzbot report of this bug:https://groups.google.com/g/syzkaller-lts-bugs/c/CVD1uqZnFPA/m/P4-Bi8BmAwAJ
>
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Kun Hu <huk23@...udan.edu.cn>, Jiaji Qin <jjtan24@...udan.edu.cn>, Shuoran Bai <baishuoran@...eu.edu.cn>
>
>
> loop4: detected capacity change from 0 to 32768
> ==================================================================
> BUG: KASAN: slab-use-after-free in diWrite+0xeb0/0x1930
> Write of size 32 at addr ffff888052f700c0 by task syz.4.12/14401
>
> CPU: 2 UID: 0 PID: 14401 Comm: syz.4.12 Not tainted 6.15.0-rc6 #1 PREEMPT(full)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
> <TASK>
> dump_stack_lvl+0x116/0x1b0
When reporting kernel bugs, please always include file:line
information so that the maintainers do not have to look it up.
(See https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md
for more hints).
Powered by blists - more mailing lists