Hi Ted, Thanks for your reply! You are right. I disabled CONFIG_BLK_DEV_WRITE_MOUNTED and found this bug can not be triggered anymore. I am wondering if there is any suggested way for me to check whether a bug is reproduced under a reasonable environment (such as compiling config) or not? If so, that would be very helpful. Best, Shuangpeng > On May 15, 2024, at 18:49, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Tue, May 14, 2024 at 08:40:36PM -0400, Shuangpeng Bai wrote: >> Hi Kernel Maintainers, >> >> Our tool found a kernel bug KASAN: use-after-free in ext4_find_extent. Please see the details below. >> >> Kernel commit: v6.9 (Commits on May 12, 2024) >> Kernel config: attachment >> C/Syz reproducer: attachment >> >> We find this bug was reported and marked as fixed. (https://syzkaller.appspot.com/bug?extid=7ec4ebe875a7076ebb31) >> >> Our reproducer can trigger this bug in v6.9, so the bug may have not been fixed correctly. > > The reason why it was marked as fixed is because the reproducer no > longer reproduces with CONFIG_BLK_DEV_WRITE_MOUNTED disabled. > Upstream syzkaller unconditionally disables this config, and we don't > consider reproducers that have CONFIG_BLK_DEV_WRITE_MOUNTED enabled to > be a bug. > > If the reproducer is actively modifying the block device (or the > underlying file for a loop device) while it is mounted, we don't > consider this a bug. This is requires root, and it's no more a > "security bug" than someone complaining that root can execute a > reboot(2) system call and calling it a "security bug". > > I've looked at your "reproducer" and it does appear to be modifying > the block device while it is mounted, and the config does have > CONFIG_BLK_DEV_WRITE_MOUNTED enabled. So I don't care (tm). If you > want to put an engineer to work on addressing the bug, and the patch > is a clean and maintable code fix, I'll certainly consider the change. > But it's not something that upstream will work on a volunteer basis; > no company I am aware of is willing to pay for engineers to work on > this sort of issue. > > Cheers, > > - Ted
