Message-ID: <eb465a29-623b-48e4-b795-201a30ae9260@gmail.com>
Date: Mon, 7 Apr 2025 19:29:45 +0200
From: Attila Szasz <szasza.contact@...il.com>
To: Christian Brauner <brauner@...nel.org>,
 Cengiz Can <cengiz.can@...onical.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
 Salvatore Bonaccorso <carnil@...ian.org>, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, lvc-patches@...uxtesting.org,
 dutyrok@...linux.org, syzbot+5f3a973ed3dfb85a6683@...kaller.appspotmail.com,
 stable@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key

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/

Powered by blists - more mailing lists