From: "Theodore Ts'o" <tytso@mit.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: 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 08:10:36 -0400 [thread overview]
Message-ID: <20250509121036.GA92783@mit.edu> (raw)
In-Reply-To: <CACT4Y+ZqToLK5R__x8O1ZctsG3wQtRn36JWF2MPRYqY+Zy_CUA@mail.gmail.com>
On Fri, May 09, 2025 at 10:03:13AM +0200, Dmitry Vyukov wrote:
>
> If we can't prove it does not have security impact in any context,
> then the safe default would be to say it's unsafe.
In that case *anything* could be unsafe. You could have a context
where (a) you aren't using secure boot, (b) /dev/mem is enabled, (c)
/dev/mem is world writeable, etc. In which case the mere existence of
/bin/bash would be "unsafe". Yes, this is uncreasonable and unsane.
But that's because the "no security impact in any context" standard is
insane.
As far as many file system authors are concerned allowing automount by
defaullt is insane, and is apparently the fault of some Red Hat
product manager many years ago.
E2fsprogs and xfsprogs now ship with a udev rule which disables
automount by default. If applied, mounting a maliciously fuzzed file
system requires root privileges.
Of course, distributions are free to change the default, just as they
are free to ship a system where root has a default password of
"password" or /bin/bash is setuid root. It would be insane, but
product managers often do insane things in the name of user
convenience. In those cases, I would invite that security researchers
file CVE's with the *product* as opposed to the upstream open source
project.
If companies want to assign me a chunk of headcount (say, 4 or 5 L4's
and L5's for 3 years working on thing but ext4 hardening, plus a
full-time L5 after that working exclusively to maintain the ext4
hardening featuers and fix random syzbot complaints), I know what I
could assign them to change the security assumptions that we have for
ext4. It might require a
CONFIG_EXT4_SECURITY_IS_MORE_IMPORTANT_THAN_PERFORMANCE parameter to
enable all of the hardening features, but it is doable.
But they aren't, so I consider it to be *obivous* that the industry
doesn't think is important --- just as Orange Book A1 certified OS's
was a total, complete, and abject commercial failure. And note, we
don't assign CVE's based on the fact that se all OS's violate the
security trust model of Orange Book's A1. :-)
- Ted
next prev parent reply other threads:[~2025-05-09 12:10 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 [this message]
2025-05-09 13:18 ` Attila Szasz
2025-05-09 13:37 ` Greg KH
2025-05-09 14:17 ` Theodore Ts'o
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=20250509121036.GA92783@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 \
/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.