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: <81a6627f-f569-4174-9d15-37615ea58458@gmail.com>
Date: Mon, 12 May 2025 19:17:31 +0200
From: Attila Szasz <szasza.contact@...il.com>
To: Theodore Ts'o <tytso@....edu>, Dmitry Vyukov <dvyukov@...gle.com>
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

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
>