Re: [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key

[Christian Brauner <brauner@kernel.org>]

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/