lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 May 2024 16:49:32 -0600
From: "Theodore Ts'o" <tytso@....edu>
To: Shuangpeng Bai <shuangpengbai@...il.com>
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller@...glegroups.com
Subject: Re: KASAN: use-after-free in ext4_find_extent in v6.9

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ