From: Greg KH <gregkh@linuxfoundation.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: 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 09:34:52 +0200 [thread overview]
Message-ID: <2025050940-marrow-roundish-8b98@gregkh> (raw)
In-Reply-To: <20250509072033.1335321-1-dvyukov@google.com>
On Fri, May 09, 2025 at 09:20:33AM +0200, Dmitry Vyukov wrote:
> > CVE-2025-0927 has now been rejected and is no longer a valid CVE.
>
> > Filesystem bugs due to corrupt images are not considered a CVE for any
> > filesystem that is only mountable by CAP_SYS_ADMIN in the initial user
> > namespace. That includes delegated mounting.
>
> I wonder if this should be the case only if the image is flagged by fsck
> as corrupted? Otherwise I am not sure what's "trusted". It's not about
> somebody's "honest eyes", right. E.g. in the context of insider risks
> the person providing an image may be considered "trusted", or in the
> context of Zero Trust Architecture nothing at all is considered trusted,
> or a trusted image may be tampered with while stored somewhere.
>
> Without any formal means to classify an image as corrupted or not,
> this approach does not look very practical to me. While flagging by fsck
> gives concrete workflow for any context that requires more security.
And how do we know of fsck can flag anything, AND which version of fsck?
We'll defer to the fs developers as to what they want here, but note, we
do not determine "trusted" or not, that is a use case that is outside of
our scope entirely.
thanks,
greg k-h
next prev parent reply other threads:[~2025-05-09 7:34 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 [this message]
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
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=2025050940-marrow-roundish-8b98@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=dvyukov@google.com \
--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.