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

Message-ID: <20250509121036.GA92783@mit.edu>
Date: Fri, 9 May 2025 08:10:36 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: 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 10:03:13AM +0200, Dmitry Vyukov wrote:
> 
> If we can't prove it does not have security impact in any context,
> then the safe default would be to say it's unsafe.

In that case *anything* could be unsafe.  You could have a context
where (a) you aren't using secure boot, (b) /dev/mem is enabled, (c)
/dev/mem is world writeable, etc.  In which case the mere existence of
/bin/bash would be "unsafe".  Yes, this is uncreasonable and unsane.
But that's because the "no security impact in any context" standard is
insane.

As far as many file system authors are concerned allowing automount by
defaullt is insane, and is apparently the fault of some Red Hat
product manager many years ago.

E2fsprogs and xfsprogs now ship with a udev rule which disables
automount by default.  If applied, mounting a maliciously fuzzed file
system requires root privileges.

Of course, distributions are free to change the default, just as they
are free to ship a system where root has a default password of
"password" or /bin/bash is setuid root.  It would be insane, but
product managers often do insane things in the name of user
convenience.  In those cases, I would invite that security researchers
file CVE's with the *product* as opposed to the upstream open source
project.

If companies want to assign me a chunk of headcount (say, 4 or 5 L4's
and L5's for 3 years working on thing but ext4 hardening, plus a
full-time L5 after that working exclusively to maintain the ext4
hardening featuers and fix random syzbot complaints), I know what I
could assign them to change the security assumptions that we have for
ext4.  It might require a
CONFIG_EXT4_SECURITY_IS_MORE_IMPORTANT_THAN_PERFORMANCE parameter to
enable all of the hardening features, but it is doable.

But they aren't, so I consider it to be *obivous* that the industry
doesn't think is important --- just as Orange Book A1 certified OS's
was a total, complete, and abject commercial failure.  And note, we
don't assign CVE's based on the fact that se all OS's violate the
security trust model of Orange Book's A1.  :-)

						- Ted