linux-kernel - Re: REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem

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] [day] [month] [year] [list]

Message-ID: <20250509141715.GC92783@mit.edu>
Date: Fri, 9 May 2025 10:17:15 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Attila Szasz <szasza.contact@...il.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>, Greg KH <gregkh@...uxfoundation.org>,
        cve@...nel.org, linux-cve-announce@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus
 filesystems with manually crafted filesystem

On Fri, May 09, 2025 at 03:18:19PM +0200, Attila Szasz wrote:
> 
> Since then, I saw Canonical folks mention that they wanted to
> allocate a new one but needed to obfuscate the description so it no
> longer sounds like a kernel bug.

Sure, it's an automounter bug; or an fsck bug, assuming that their
system is running fsck -y on the file system before trying to mount
the file system.

> Which, incidentally, is not quite true either, it *is* a kernel bug.
> 
> Since then I checked, and 5.4 LTS (any<=5.6) had been vulnerable without
> the need to ever mount an untrusted/malformed FS just by systematically
> corrupting a vanilla fs's B-trees with normal operations.

So if you can come up with a reproducer that *starts* with a valid
file system which passes fsck, and then using normal, non-root
operations, you can corrupt the file system and then trigger a kernel
crash or some vulnerability, then that's a valid security bug in my
opinion.  I'll certainly treat it that way for ext4.

But you need to demonstrate this using a reproducer that doesn't start
with a fuzzed file system.  In my experience, this rules out 99% of
syzbot bugs reported against ext4.  But if you can come up with such a
reproducer, send the POC to the file system developer, and ask them to
address it.  If it's against ext4, I'll get on it right away.

> There was also a logic issue I wrote about that hasn't been
> patched, since hfs_brec_find() can return with -ENOENT, and
> hfsplus_create_attr did not treat ENOENT as a problem when
> inserting records, resulting in a flow completely missing the
> only boundary checks that were present earlier. With the issue
> that commit 25efb2f patched upstream and another issue I found,
> the condition for the rejection is no longer true.
> The image to begin with is not even corrupt.

Great, but that's not this CVE.  Note that it was entitled "... with
manually crafted filesystem"

						- Ted