From: "Theodore Ts'o" <tytso@mit.edu>
To: Attila Szasz <szasza.contact@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
cve@kernel.org, linux-cve-announce@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem
Date: Fri, 9 May 2025 10:17:15 -0400 [thread overview]
Message-ID: <20250509141715.GC92783@mit.edu> (raw)
In-Reply-To: <6191c255-84cc-4721-91d1-1884472989f7@gmail.com>
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
next prev parent reply other threads:[~2025-05-09 14:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-30 18:55 CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem Greg Kroah-Hartman
2025-04-02 6:51 ` [PATCH 1/2] published: CVE-2025-0927: Fix up JSON schema Siddh Raman Pant
2025-04-02 6:51 ` [PATCH 2/2] published: CVE-2025-0927: Rearrange fields in JSON Siddh Raman Pant
2025-04-02 7:06 ` Greg Kroah-Hartman
2025-04-02 7:06 ` [PATCH 1/2] published: CVE-2025-0927: Fix up JSON schema Greg Kroah-Hartman
2025-04-02 7:16 ` Siddh Raman Pant
2025-04-02 7:41 ` gregkh
2025-04-02 7:07 ` Greg Kroah-Hartman
2025-04-08 8:06 ` REJECTED: CVE-2025-0927: heap overflow in the hfs and hfsplus filesystems with manually crafted filesystem Greg Kroah-Hartman
2025-05-09 7:20 ` Dmitry Vyukov
2025-05-09 7:34 ` Greg KH
2025-05-09 7:47 ` Dmitry Vyukov
2025-05-09 7:55 ` Greg KH
2025-05-09 8:03 ` Dmitry Vyukov
2025-05-09 12:10 ` Theodore Ts'o
2025-05-09 13:18 ` Attila Szasz
2025-05-09 13:37 ` Greg KH
2025-05-09 14:17 ` Theodore Ts'o [this message]
2025-05-12 13:22 ` Dmitry Vyukov
2025-05-12 14:44 ` Theodore Ts'o
2025-05-12 17:17 ` Attila Szasz
2025-05-13 7:09 ` Dmitry Vyukov
2025-05-13 12:05 ` Theodore Ts'o
2025-05-13 16:09 ` Dmitry Vyukov
2025-05-13 21:43 ` Theodore Ts'o
2025-05-14 4:53 ` Dmitry Vyukov
2025-05-21 8:20 ` Dmitry Vyukov
2025-05-23 12:51 ` Greg KH
2025-05-09 14:05 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250509141715.GC92783@mit.edu \
--to=tytso@mit.edu \
--cc=cve@kernel.org \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=szasza.contact@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.