public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Attila Szasz <szasza.contact@gmail.com>
To: Christian Brauner <brauner@kernel.org>,
	Cengiz Can <cengiz.can@canonical.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Salvatore Bonaccorso <carnil@debian.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	lvc-patches@linuxtesting.org, dutyrok@altlinux.org,
	syzbot+5f3a973ed3dfb85a6683@syzkaller.appspotmail.com,
	stable@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key
Date: Mon, 7 Apr 2025 19:29:45 +0200	[thread overview]
Message-ID: <eb465a29-623b-48e4-b795-201a30ae9260@gmail.com> (raw)
In-Reply-To: <20250407-kumpel-klirren-ad0db3c77321@brauner>

Christian,

It was Greg who moved this CVE under the kernel.org CNA territory:

https://lore.kernel.org/lkml/2025032402-jam-immovable-2d57@gregkh/

This thread was kicked into gear by Salvatore from Debian, who asked 
whether there was a mainline fix. There wasn’t one upstream, I think, 
primarily due to your assessment.

Meanwhile, the distros wanted to protect their users and fix that gaping 
64k heap buffer overflow with a one-liner boundary check. Canonical did. 
I believe they wanted to help Debian do the same.

They assigned a CVE -with the ID you are seeing- for Canonical Ubuntu Linux:

https://github.com/CVEProject/cvelist/commit/a56d5efc25a561c94ccf296fceaab2a01dc4bc01

It seems Debian initially dropped the config option altogether — a 
reasonable decision I personally agree with — but later reverted the 
change after someone from SuSE pointed out that it’s still required for 
PowerPC, PPC64, and apparently some Apple hardware:
https://salsa.debian.org/kernel-team/linux/-/commit/180f39f01cb9175dc77e8a5e27b78b5d1537752e#note_598347

Still, I think the distros were just trying to do their jobs. Something 
that it seems we might both agree on.

On 4/7/25 19:15, Christian Brauner wrote:
> On Mon, Apr 07, 2025 at 12:59:18PM +0200, Christian Brauner wrote:
>> On Sun, Apr 06, 2025 at 07:07:57PM +0300, Cengiz Can wrote:
>>> On 24-03-25 11:53:51, Greg KH wrote:
>>>> On Mon, Mar 24, 2025 at 09:43:18PM +0300, Cengiz Can wrote:
>>>>> In the meantime, can we get this fix applied?
>>>> Please work with the filesystem maintainers to do so.
>>> Hello Christian, hello Alexander
>>>
>>> Can you help us with this?
>>>
>>> Thanks in advance!
>> 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.
>>
>> Now, quoting from [1]:
>>
>> "So, for the record, the Linux kernel in general only allows mounts for
>> those with CAP_SYS_ADMIN, however, it is true that desktop and even
>> server environments allow regular non-privileged users to mount and
>> automount filesystems.
>>
>> In particular, both the latest Ubuntu Desktop and Server versions come
>> with default polkit rules that allow users with an active local session
>> to create loop devices and mount a range of block filesystems commonly
>> found on USB flash drives with udisks2. Inspecting
>> /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy shows:"
>>
>> So what this saying is:
>>
>> A distribution is shipping tooling that allows unprivileged users to mount
>> arbitrary filesystems including hpfsplus. Or to rephrase this: A
>> distribution is allowing unprivileged users to mount orphaned
>> filesystems. Congratulations on the brave decision to play Russian
>> Roulette with a fully-loaded gun.
>>
>> The VFS doesn't allow mounting arbitrary filesystems by unprivileged
>> users. Every FS_REQUIRES_DEV filesystem requires global CAP_SYS_ADMIN
>> privileged at which point you can also do sudo rm -rf --no-preserve-root /
>> or a million other destructive things.
>>
>> The blogpost is aware that the VFS maintainers don't accept CVEs like
>> this. Yet a CVE was still filed against the upstream kernel. IOW,
>> someone abused the fact that a distro chose to allow mounting arbitrary
>> filesystems including orphaned ones by unprivileged user as an argument
>> to gain a kernel CVE.
>>
>> Revoke that CVE against the upstream kernel. This is a CVE against a
>> distro. There's zero reason for us to hurry with any fix.
> Before that gets misinterpreted: This is not intended to either
> implicitly or explicitly imply that patch pickup is dependend on the
> revocation of this CVE.
>
> Since this isn't a valid CVE there's no reason to hurry-up merging this
> into mainline within the next 24 hours. It'll get there whenever the
> next fixes pr is ready.
>
>> [1]: https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/

  reply	other threads:[~2025-04-07 17:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-19 19:13 [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key Vasiliy Kovalev
2025-03-20 19:30 ` Salvatore Bonaccorso
2025-03-24 16:14   ` Cengiz Can
2025-03-24 16:17     ` Greg KH
2025-03-24 18:43       ` Cengiz Can
2025-03-24 18:53         ` Greg KH
2025-04-06 16:07           ` Cengiz Can
2025-04-06 16:28             ` Greg KH
2025-04-07 10:59             ` Christian Brauner
2025-04-07 17:15               ` Christian Brauner
2025-04-07 17:29                 ` Attila Szasz [this message]
2025-04-07 19:08               ` Darrick J. Wong
2025-04-08 10:11                 ` Richard Weinberger
2025-04-08 14:50                   ` Darrick J. Wong
2025-04-08 15:58                     ` Richard Weinberger
2025-04-16 15:10                   ` Eric Sandeen
2025-04-08  8:03               ` Greg KH
2025-04-08 12:00                 ` Attila Szasz
2025-03-27 19:15       ` Attila Szasz
2025-04-07 17:25 ` Christian Brauner

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=eb465a29-623b-48e4-b795-201a30ae9260@gmail.com \
    --to=szasza.contact@gmail.com \
    --cc=brauner@kernel.org \
    --cc=carnil@debian.org \
    --cc=cengiz.can@canonical.com \
    --cc=dutyrok@altlinux.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvc-patches@linuxtesting.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+5f3a973ed3dfb85a6683@syzkaller.appspotmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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