Message-ID: <6191c255-84cc-4721-91d1-1884472989f7@gmail.com>
Date: Fri, 9 May 2025 15:18:19 +0200
From: Attila Szasz <szasza.contact@...il.com>
To: Theodore Ts'o <tytso@....edu>, 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

 > I would invite that security researchers
> file CVE's with the *product* as opposed to the upstream open source
> project.

The CVE was originally filed for Ubuntu Linux ;)
Namely, cpe:2.3:o:canonical:ubuntu_linux.

It was moved to kernel.org CNA territory due to some politics,
then it was rejected on the same day the bug was fixed upstream.

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.

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.
       

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.

According to this, https://lwn.net/Articles/652468/, user namespace
mounting for block filesystems *was seriously considered*
at some point, but it was deemed too hard or costly.
But ok, so it is "doable" in theory.

Then, it is just not consistent with the rest of your CNA practices to
blame users for relaxing requirements on mounting, and as this shows,
this was not even the case here for one of the LTS stables.

I think the delegated threat model is a difficult one, but you kind of
chose this yourselves with the CNA policy of treating most bugs as
potentially exploitable.


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

No, you (or more like cve@) assign CVEs on panic_on_warn noise instead:)

On 5/9/25 14:10, Theodore Ts'o 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.
>
> 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
>

Powered by blists - more mailing lists