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+boJEGtmFsKzi326ra+-ck7oV9oq1T561_VAjiE9OCVjQ@mail.gmail.com>
Date: Wed, 14 May 2025 06:53:15 +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 23:43, Theodore Ts'o <tytso@....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