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

[Darrick J. Wong]

On Tue, Apr 08, 2025 at 12:11:36PM +0200, Richard Weinberger wrote:
> On Mon, Apr 7, 2025 at 9:08 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
> > It's also the default policy on Debian 12 and RHEL9 that if you're
> > logged into the GUI, any program can run:
> >
> > $ truncate -s 3g /tmp/a
> > $ mkfs.hfs /tmp/a
> > $ <write evil stuff on /tmp/a>
> > $ udisksctl loop-setup -f /tmp/a
> > $ udisksctl mount -b /dev/loopX
> >
> > and the user never sees a prompt.  GNOME and KDE both display a
> > notification when the mount finishes, but by then it could be too late.
> > Someone should file a CVE against them too.
> 
> At least on SUSE orphaned and other problematic filesystem kernel modules
> are blacklisted. I wonder why other distros didn't follow this approach.

Maximal flexibility, I'm assuming.  It's at least somewhat comforting
that RHEL doesn't enable HFS in Kconfig so it's a nonissue for them, but
some day it's going to be ext4/XFS/btrfs that creates a compromise
widget.

> > You can tighten this up by doing this:
> >
> > # cat > /usr/share/polkit-1/rules.d/always-ask-mount.rules << ENDL
> > // don't allow mounting, reformatting, or loopdev creation without asking
> > polkit.addRule(function(action, subject) {
> >         if ((action.id == "org.freedesktop.udisks2.loop-setup" ||
> >              action.id == "org.freedesktop.udisks2.filesystem-mount" ||
> >              action.id == "org.freedesktop.udisks2.modify-device") &&
> >             subject.local == true) {
> >                 return polkit.Result.AUTH_ADMIN_KEEP;
> >         }
> > });
> > ENDL
> 
> Thanks for sharing this!
> 
> > so at least you have to authenticate with an admin account.  We do love
> > our footguns, don't we?  At least it doesn't let you do that if you're
> > ssh'd in...
> 
> IMHO guestmount and other userspace filesystem implementations should
> be the default
> for such mounts.

Agree.  I don't know if they (udisks upstream) have any good way to
detect that a userspace filesystem driver is available for a given
filesystem.  Individual fuse drivers don't seem to have a naming
convention (fusefat, fuse2fs) though at least on Debian some of them
seem to end up as /sbin/mount.fuse.$FSTYPE.

guestmount seems to boot the running kernel in qemu and use that?  So I
guess it's hard for guestmount itself even to tell you what formats it
supports?  I'm probably just ignorant on that issue.

--D

> //richard
>