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

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, May 21, 2025 at 10:20:10AM +0200, Dmitry Vyukov wrote:
> On Fri, 9 May 2025 at 09:55, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, May 09, 2025 at 09:47:20AM +0200, Dmitry Vyukov wrote:
> > > On Fri, 9 May 2025 at 09:34, Greg KH <gregkh@linuxfoundation.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?
> >
> > That requires us to attempt to reproduce stuff when assigning CVEs?
> >
> > And what architecture/target?  How do we do this for all of them?
> >
> > Remember, we are averaging 13 CVE assignments a day, this has to be
> > automated in order for us to be able to manage this with the volunteer
> > staff we have.
> >
> > > > 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.
> >
> > Remember older kernels are updated but userspace isn't on many
> > platforms, so the combinations of userspace tools and the kernel
> > versions is not anything we are going to even be aware of.
> >
> > > > 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 :)
> >
> > This is open source, we can not, and do not, dictate use.  It is up to
> > the users of our software to determine if their use case matches up with
> > the reported vulnerability or not.  We can not do it the other way
> > around, that is impossible from our side.
> 
> So based on this, and Ted's confirmation that using fsck to validate
> images is valid [1], it looks like we should create CVEs for such
> bugs, right?

If you know of any that we have missed, please let us know.

So yes, we can assign them if people ask for them.

thanks,

greg k-h