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+Y+E6xnOOJ8zwSdy09FT-OLPPYVFLvZsdpEOkYQ2vsTRg@mail.gmail.com>
Date: Tue, 13 May 2025 18:09:24 +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 Tue, 13 May 2025 at 14:05, Theodore Ts'o <tytso@....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.
>