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+as-Uy_BUjLDxfNwC2+78U3kJdaaKL=vbUNMZH9VcLiGQ@mail.gmail.com>
Date: Tue, 13 May 2025 09:09:34 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: "Theodore Ts'o" <tytso@....edu>
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 Mon, 12 May 2025 at 16:44, Theodore Ts'o <tytso@....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.