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: <CACT4Y+Z8ANddFCpNHvNqq6u6=s_aWoYPwu_1HmH19OWeLBi47A@mail.gmail.com>
Date: Mon, 12 May 2025 15:22:12 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: "Theodore Ts'o" <tytso@....edu>
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, 9 May 2025 at 14:10, Theodore Ts'o <tytso@....edu> wrote:
>
> 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.

The official documented behavior is not unsafe. If a user made
/dev/mem world-writable, then allowing any writes to it is not a bug
nor a security issue. Let's not mix working-as-intended with bugs.

> 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.

This is not even about auto-mount. Let's say I am mounting a flash
drive that you gave me, how do I ensure it's a safe image to mount?
Removable media, portable drives, and some use cases related to
mounting images stored in local files either deal with images with
unknown origin, or can't provide 100% guarantee that the image wasn't
tempered with.


> 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.

Question of resources for fixing is orthogonal to classification of an
issue (if it's a bug or not, if it's a security issue or not).


> 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