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+aiQcbHfj2rB6pGKevUbUoYwrHMu+aC-xh0BCKE8D-8sQ@mail.gmail.com>
Date: Fri, 9 May 2025 09:47:20 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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 09:34, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Fri, May 09, 2025 at 09:20:33AM +0200, Dmitry Vyukov wrote:
> > > CVE-2025-0927 has now been rejected and is no longer a valid CVE.
> >
> > > Filesystem bugs due to corrupt images are not considered a CVE for any
> > > filesystem that is only mountable by CAP_SYS_ADMIN in the initial user
> > > namespace. That includes delegated mounting.
> >
> > I wonder if this should be the case only if the image is flagged by fsck
> > as corrupted? Otherwise I am not sure what's "trusted". It's not about
> > somebody's "honest eyes", right. E.g. in the context of insider risks
> > the person providing an image may be considered "trusted", or in the
> > context of Zero Trust Architecture nothing at all is considered trusted,
> > or a trusted image may be tampered with while stored somewhere.
> >
> > Without any formal means to classify an image as corrupted or not,
> > this approach does not look very practical to me. While flagging by fsck
> > gives concrete workflow for any context that requires more security.
>
> And how do we know of fsck can flag anything,

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.

> We'll defer to the fs developers as to what they want here, but note, we
> do not determine "trusted" or not, that is a use case that is outside of
> our scope entirely.

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