Re: REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem

[Dmitry Vyukov]

On Fri, 9 May 2025 at 09:34, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 :)