mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
>

  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®