From: Attila Szasz <szasza.contact@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, 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: Mon, 12 May 2025 19:17:31 +0200 [thread overview]
Message-ID: <81a6627f-f569-4174-9d15-37615ea58458@gmail.com> (raw)
In-Reply-To: <20250512144402.GA200944@mit.edu>
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
>
next prev parent reply other threads:[~2025-05-12 17:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2025040820-REJECTED-6695@gregkh>
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
2025-05-12 13:22 ` Dmitry Vyukov
2025-05-12 14:44 ` Theodore Ts'o
2025-05-12 17:17 ` Attila Szasz [this message]
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=81a6627f-f569-4174-9d15-37615ea58458@gmail.com \
--to=szasza.contact@gmail.com \
--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=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®