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

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

[Dmitry Vyukov]

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

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

[Greg KH]

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, AND which version of fsck?

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.

thanks,

greg k-h

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@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?

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

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

[Greg KH]

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.

thanks,

greg k-h

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

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.
That's the current Kernel CNA approach, right. It creates a super set
of any issues that may be relevant in some context.


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

Indeed. And for that we need to flag it as a potential vulnerability
in the first place.

But the current rule says it's not a vulnerability for any possible
user and use case out there.

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

[Theodore Ts'o]

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

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

[Attila Szasz]

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

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

[Greg KH]

On Fri, May 09, 2025 at 03:18:19PM +0200, Attila Szasz wrote:
> > 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,

There was no "politics" here, no other CNA is allowed to assign bugs
against Linux without going through cve@kernel.org first.  That's just
how the CVE system works, Canonical should not have assigned that from
the beginning.

It happens at times, nothing special here, Oracle did it earlier this
week as well, and we had to reassign a CVE over to us.  Other CNAs have
done it in the past too when they forgot that Linux was a CNA.

> then it was rejected on the same day the bug was fixed upstream.

That was based on the request of the filesystem maintainers, which we
use as the final word on these things.

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

That's great to hear, please let me know when they do that so that we
all can report them for violating their CNA agreement with CVE.org :)

thanks,

greg k-h

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

[Theodore Ts'o]

On Fri, May 09, 2025 at 03:18:19PM +0200, Attila Szasz wrote:
> 
> 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.

Sure, it's an automounter bug; or an fsck bug, assuming that their
system is running fsck -y on the file system before trying to mount
the file system.

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

So if you can come up with a reproducer that *starts* with a valid
file system which passes fsck, and then using normal, non-root
operations, you can corrupt the file system and then trigger a kernel
crash or some vulnerability, then that's a valid security bug in my
opinion.  I'll certainly treat it that way for ext4.

But you need to demonstrate this using a reproducer that doesn't start
with a fuzzed file system.  In my experience, this rules out 99% of
syzbot bugs reported against ext4.  But if you can come up with such a
reproducer, send the POC to the file system developer, and ask them to
address it.  If it's against ext4, I'll get on it right away.

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

Great, but that's not this CVE.  Note that it was entitled "... with
manually crafted filesystem"

						- Ted

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 14:10, Theodore Ts'o <tytso@mit.edu> 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.

The official documented behavior is not unsafe. If a user made
/dev/mem world-writable, then allowing any writes to it is not a bug
nor a security issue. Let's not mix working-as-intended with bugs.

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

This is not even about auto-mount. Let's say I am mounting a flash
drive that you gave me, how do I ensure it's a safe image to mount?
Removable media, portable drives, and some use cases related to
mounting images stored in local files either deal with images with
unknown origin, or can't provide 100% guarantee that the image wasn't
tempered with.


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

Question of resources for fixing is orthogonal to classification of an
issue (if it's a bug or not, if it's a security issue or not).


> 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

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

[Theodore Ts'o]

On Mon, May 12, 2025 at 03:22:12PM +0200, Dmitry Vyukov wrote:
> 
> This is not even about auto-mount. Let's say I am mounting a flash
> drive that you gave me, how do I ensure it's a safe image to mount?
> Removable media, portable drives, and some use cases related to
> mounting images stored in local files either deal with images with
> unknown origin, or can't provide 100% guarantee that the image wasn't
> tempered with.

From my perspective, the answer is simple.

You run fsck -y on the file system image.  If fsck.FSTYP isn't capable
of sanitizding the file system image to make it be safe, then that
should be considered a security bug for fsck.FSTYP, and should be
reported as such.

Does the user not have the latest version of fsck?  Well, they should.
If they don't have the latest version of the kernel, or any other
system software in the TCB, then they could be unsafe.  And that's on
the user.

> Question of resources for fixing is orthogonal to classification of an
> issue (if it's a bug or not, if it's a security issue or not).

No, but the resources available should inform the trust model, and
assuming that users should be able to blindly insert any random USB
thumb drive, or blindly mounting any untrusted file system image, is
not a trust model that is realistic.

If you want a different trust model, then give me the resources.
Otherwise, don't try to impose an unfunded mandate on me.  Because I
will ignore you, for the sake of my mental health if nothing else.

     	    	     	      	 - Ted

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

[Attila Szasz]

At their core, tough software decisions often involve economic trade-offs,
weighing ideal solutions against practical constraints like development 
time,
budget, and acceptable risk. This doesn't make a particular decision
fundamentally wrong from a computer science or program correctness (à la
Dijkstra) standpoint, but rather reflects the real-world limitations under
which software is built.

Mounting pendrives in 2025? We're just not there yet.

On 5/12/25 16:44, Theodore Ts'o wrote:
> On Mon, May 12, 2025 at 03:22:12PM +0200, Dmitry Vyukov wrote:
>> This is not even about auto-mount. Let's say I am mounting a flash
>> drive that you gave me, how do I ensure it's a safe image to mount?
>> Removable media, portable drives, and some use cases related to
>> mounting images stored in local files either deal with images with
>> unknown origin, or can't provide 100% guarantee that the image wasn't
>> tempered with.
> >From my perspective, the answer is simple.
>
> You run fsck -y on the file system image.  If fsck.FSTYP isn't capable
> of sanitizding the file system image to make it be safe, then that
> should be considered a security bug for fsck.FSTYP, and should be
> reported as such.
>
> Does the user not have the latest version of fsck?  Well, they should.
> If they don't have the latest version of the kernel, or any other
> system software in the TCB, then they could be unsafe.  And that's on
> the user.
>
>> Question of resources for fixing is orthogonal to classification of an
>> issue (if it's a bug or not, if it's a security issue or not).
> No, but the resources available should inform the trust model, and
> assuming that users should be able to blindly insert any random USB
> thumb drive, or blindly mounting any untrusted file system image, is
> not a trust model that is realistic.
>
> If you want a different trust model, then give me the resources.
> Otherwise, don't try to impose an unfunded mandate on me.  Because I
> will ignore you, for the sake of my mental health if nothing else.
>
>       	    	     	      	 - Ted
>

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

[Dmitry Vyukov]

On Mon, 12 May 2025 at 16:44, Theodore Ts'o <tytso@mit.edu> wrote:
> > This is not even about auto-mount. Let's say I am mounting a flash
> > drive that you gave me, how do I ensure it's a safe image to mount?
> > Removable media, portable drives, and some use cases related to
> > mounting images stored in local files either deal with images with
> > unknown origin, or can't provide 100% guarantee that the image wasn't
> > tempered with.
>
> From my perspective, the answer is simple.
>
> You run fsck -y on the file system image.  If fsck.FSTYP isn't capable
> of sanitizding the file system image to make it be safe, then that
> should be considered a security bug for fsck.FSTYP, and should be
> reported as such.
>
> Does the user not have the latest version of fsck?  Well, they should.
> If they don't have the latest version of the kernel, or any other
> system software in the TCB, then they could be unsafe.  And that's on
> the user.
>
> > Question of resources for fixing is orthogonal to classification of an
> > issue (if it's a bug or not, if it's a security issue or not).
>
> No, but the resources available should inform the trust model, and
> assuming that users should be able to blindly insert any random USB
> thumb drive, or blindly mounting any untrusted file system image, is
> not a trust model that is realistic.
>
> If you want a different trust model, then give me the resources.
> Otherwise, don't try to impose an unfunded mandate on me.  Because I
> will ignore you, for the sake of my mental health if nothing else.

So the current model is that anybody who may have access to the image
is considered the same level of trust as loading unsigned modules,
right?

I just hoped for something at least somewhat stronger. Bugs flagged by
fsck won't require fixing in that model.

It's not necessarily about a completely "random USB thumb drive".
There may be some level of trust + the image passes fsck. E.g. handout
material on workshops (when one needs to distribute X GB to N people,
conference wifi may be not the best option).
Or, insider risk inside of a company where an image is prepared by
another employee.

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

[Theodore Ts'o]

On Tue, May 13, 2025 at 09:09:34AM +0200, Dmitry Vyukov wrote:
> I just hoped for something at least somewhat stronger. Bugs flagged by
> fsck won't require fixing in that model.

Well, if you have the budget and the headcount to back up that hope,
you know where to reach me.  Personally, I've hoped to win the lottery
and own a private jet, but given that I'm not willing to pay the $$$
for the private jet --- I fly economy.

Consider carabiners.  I have one that I use for fastening my keys to
my belt loop or knapsack. But there are also carabiners that are
certified for climbing.  If you try to use the former for climbing, it
wouldn't be safe.  But the climbing carabiner is a lot more expensive
and a lot heavier.

As far as file systems are concerned, a hardened file system will be
more expensive, and will have less performance.  But if you are using
file systems in a data center, where the hard drive is in within the
Trusted Computing Base, paying the costs for a hardened file system is
silly.  And in fact, companies are not silly; I have yet to work for a
company, including my current employer, which has been willing to
invest in a hardened file system.

Now, the good news is that there are ways we can use a non-hardened
file system in a safe way.  You just to have the system enforce the
constraint that the file system must be fsck'ed before mounting the
file system.

If you want to be even more paranoid (or the proprietary file system
doesn't have a good fsck), you could mount the file system via a guest
kernel running in a VM, where the VM is locked down using a seccomp
sandbox, and which provides file system services via 9pfs to the host
kernel.  9pfs is a remote file system which is easy to audit, and this
is a key part of the security strategy used by gVisor.

See?  Easy peasy!  And far cheaper than attempting to harden a file
system.

						- Ted

P.S.  If some company wants the equivalent of a titanium carabiner,
where we invest a huge amount of SWE effort in making a hardened file
system which is as performant as possible, I'm certainly willing to
work with such a team.  I haven't yet seen the business case where the
ROI makes sense, but perhaps some company has a unique situation where
such an investment makes sense.

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

[Dmitry Vyukov]

On Tue, 13 May 2025 at 14:05, Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Tue, May 13, 2025 at 09:09:34AM +0200, Dmitry Vyukov wrote:
> > I just hoped for something at least somewhat stronger. Bugs flagged by
> > fsck won't require fixing in that model.
>
> Well, if you have the budget and the headcount to back up that hope,
> you know where to reach me.  Personally, I've hoped to win the lottery
> and own a private jet, but given that I'm not willing to pay the $$$
> for the private jet --- I fly economy.
>
> Consider carabiners.  I have one that I use for fastening my keys to
> my belt loop or knapsack. But there are also carabiners that are
> certified for climbing.  If you try to use the former for climbing, it
> wouldn't be safe.  But the climbing carabiner is a lot more expensive
> and a lot heavier.
>
> As far as file systems are concerned, a hardened file system will be
> more expensive, and will have less performance.  But if you are using
> file systems in a data center, where the hard drive is in within the
> Trusted Computing Base, paying the costs for a hardened file system is
> silly.  And in fact, companies are not silly; I have yet to work for a
> company, including my current employer, which has been willing to
> invest in a hardened file system.
>
> Now, the good news is that there are ways we can use a non-hardened
> file system in a safe way.  You just to have the system enforce the
> constraint that the file system must be fsck'ed before mounting the
> file system.

Ted, have you read what this thread is about? :)
I was talking only about images that fail fsck.

Re headcount, if we want that to ever happen, shouldn't we do what I proposed?

If we downplay all of these, pretend these don't exist, and argue it's
not important in any context, unsurprisingly nobody is willing to
allocate a headcount to fix this "unimportant nothing".


> If you want to be even more paranoid (or the proprietary file system
> doesn't have a good fsck), you could mount the file system via a guest
> kernel running in a VM, where the VM is locked down using a seccomp
> sandbox, and which provides file system services via 9pfs to the host
> kernel.  9pfs is a remote file system which is easy to audit, and this
> is a key part of the security strategy used by gVisor.
>
> See?  Easy peasy!  And far cheaper than attempting to harden a file
> system.
>
>                                                 - Ted
>
> P.S.  If some company wants the equivalent of a titanium carabiner,
> where we invest a huge amount of SWE effort in making a hardened file
> system which is as performant as possible, I'm certainly willing to
> work with such a team.  I haven't yet seen the business case where the
> ROI makes sense, but perhaps some company has a unique situation where
> such an investment makes sense.
>

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

[Theodore Ts'o]

On Tue, May 13, 2025 at 06:09:24PM +0200, Dmitry Vyukov wrote:
> 
> Ted, have you read what this thread is about? :)
> I was talking only about images that fail fsck.

If it fails fsck, don't mount the !@?@# image.  For ext4, we can fix
pretty much any corrption, so using fsck.ext4 -y should work for nearly all
file system images.

> Re headcount, if we want that to ever happen, shouldn't we do what I proposed?

Do what?  Tell users that they should be able to mount untrusted file
systems that fail fsck, and after we have a catastrophic security
failure, hope that someone will fund it?  I don't think that's very
responsible.

Or did you mean spamming open source volunteers with syzbot reports
hoping that you can shame/abuse them to do the work for free?  Sorry,
that's not going to work.  It's just way too much of a lift ---
multiple SWE-years worth of work is not something that I'm going to do
after midnight or on weekends.

If you really want to mount file systesms that fail fsck, or you're
too lazy to run fsck on untrusted images (and this shouldn't be hard
to teach the desktop software check the file system automatically
before auto-mounting it), then another possibility is:

> > If you want to be even more paranoid (or the proprietary file system
> > doesn't have a good fsck), you could mount the file system via a guest
> > kernel running in a VM, where the VM is locked down using a seccomp
> > sandbox, and which provides file system services via 9pfs to the host
> > kernel.  9pfs is a remote file system which is easy to audit, and this
> > is a key part of the security strategy used by gVisor.

       	     	     	 	  	   - Ted

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

[Dmitry Vyukov]

On Tue, 13 May 2025 at 23:43, Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Tue, May 13, 2025 at 06:09:24PM +0200, Dmitry Vyukov wrote:
> >
> > Ted, have you read what this thread is about? :)
> > I was talking only about images that fail fsck.
>
> If it fails fsck, don't mount the !@?@# image.  For ext4, we can fix
> pretty much any corrption, so using fsck.ext4 -y should work for nearly all
> file system images.
>
> > Re headcount, if we want that to ever happen, shouldn't we do what I proposed?
>
> Do what?  Tell users that they should be able to mount untrusted file
> systems that fail fsck, and after we have a catastrophic security
> failure, hope that someone will fund it?  I don't think that's very
> responsible.

The other way around: if it passes fsck, but still triggers a kernel
bug, then the bug should get CVE.

> Or did you mean spamming open source volunteers with syzbot reports
> hoping that you can shame/abuse them to do the work for free?  Sorry,
> that's not going to work.  It's just way too much of a lift ---
> multiple SWE-years worth of work is not something that I'm going to do
> after midnight or on weekends.
>
> If you really want to mount file systesms that fail fsck, or you're
> too lazy to run fsck on untrusted images (and this shouldn't be hard
> to teach the desktop software check the file system automatically
> before auto-mounting it), then another possibility is:
>
> > > If you want to be even more paranoid (or the proprietary file system
> > > doesn't have a good fsck), you could mount the file system via a guest
> > > kernel running in a VM, where the VM is locked down using a seccomp
> > > sandbox, and which provides file system services via 9pfs to the host
> > > kernel.  9pfs is a remote file system which is easy to audit, and this
> > > is a key part of the security strategy used by gVisor.
>
>                                            - Ted

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

Re making the process scalable and what version of fsck to use, I
think it's reasonable to offload this to users. If they use fsck for
validation, they can check a particular CVE if it's caught by _their_
version of fsck, and if yes, ignore such CVEs.
This looks in line with the rest of the CVE process. Some users don't
enable some configs. Kernel CNA still creates a CVE, a user checks
that this CVE is related to config they don't enable and ignores the
CVE.

[1] https://lore.kernel.org/all/20250513120549.GA9943@mit.edu/

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

[Greg KH]

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

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

[Theodore Ts'o]

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