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: <20250509140537.GB92783@mit.edu>
Date: Fri, 9 May 2025 10:05:37 -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 09:47:20AM +0200, Dmitry Vyukov wrote:
> By running fsck on the image. Or what do you mean?
> 
> > AND which version of fsck?
> 
> This needs to be answered as part of establishing the vulnerability
> triage process. I would go for a relatively fresh version. That will
> remove bugs fixed a long time ago, and if users rely on it for
> security purposes they have to update it.

If someone can come up with a fuzzed file system that can cause
fsck.ext4 to crash, or which fsck.ext4 can't fix said corruption such
that any kernel in the last 5 years (or heck, I'll be generous,
*ever*) results in a kernel crash or vulnerability, feel free to file
the security bug against e2fsprogs.

The last time an image triggered a e2fsck crash was three years ago
(CVE-2022-1304), and the last time that fsck.ext4 failed to fix a
corruption which could trigger a kernel issue was six years ago
(CVE-2019-5094).

My only caveat here is that it needs to be a real crash --- if it's
some bullsh*t fuzzer that treats e2fsck using more than 6 megabytes as
a "security vulnerability" that I have to fix in 30 days or "we will
tell the world", I'll stop engaging with the fuzzer project (i.e.,
oss-fuzz).  As far as I'm concerned, calling things like this a
security vulnerability says a lot more about fuzzer project than
e2fsprogs.  There are security research labs (such as TALOS) that can
send me security reports for e2fsprogs that doesn't waste my time.

In any case, if fsck can't fix the problem, then it's a e2fsprogs CVE,
not a kernel CVE --- so it's not something the kernel cVE process
needs to take into account.  If it's a corrupted file system image,
then fsck.ext4 should fix it, and if it can't, that's an e2fsprogs issue.

> I think classification should be tied to users and use cases in the
> first place. I, as a developer, wouldn't want any CVEs assigned to my
> code, if I could just wish so :)

I think classifications should be tied to what develoeprs say is a
valid way to use their code.  If users do something irrresponsible,
that's the user's fault.  And if the product ships the system in an
insecure default, then it's a security problem with the product.

	 	       	      	       	       - Ted