Re: Linux kernel: HFS+ filesystem implementation issues, exposure in distros

[Attila Szasz <szasza.contact () gmail com>]

> OTOH, is there other significant security impact?  As I understood, on
> Ubuntu a privileged logged in user could use this bug to obtain root.
> However, is that user perhaps privileged enough to also sudo to root by
> default?  So is this only a bypass of the need to re-enter the user's
> password for sudo?  That sudo from user to root is only a nominal
> protection mechanism anyway, more against inadvertent mistakes than
> against malicious attacks.

I didn't make this explicit in the video, but this works when
running as a non-sudoer user, and also on Ubuntu Server. I think
Canonical Product Security might have better estimates on this, but
I'm guessing many of the corporate, gov, academic, HPC cluster, etc
use cases are impacted practically in such a setting.

Also, many customers ofhttps://ubuntu.com/pro, I think.
Incidentally, I don't know how active user sessions in polkit and the
state of being a sudoer vs non-sudoer works when you hook up workstations
to AD, but it might be interesting.

On 6/2/25 22:59, Solar Designer wrote:
[..]

> If nothing else, this can be used to bypass UEFI Secure Boot.

Could be. Also, I know that Debian wanted to disable hfs/hfsplus
altogether in kernel config, but it was pointed out that
powerpc and ppc64 still needs that - I guess for booting properly.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/1422
https://github.com/AOSC-Tracking/debian-kernel-team-linux/commit/9b5d19e4bb14e65ff3295e7af394f4048a3bfba0
https://salsa.debian.org/kernel-team/linux/-/commit/d522d84d1b39689b31030eda65b33b29bada5a9a

> Do I correctly read "(any<=5.6)" as indicating that the filesystem 
> corruption bug has been fixed for a long time now?

Yeah, so there was a fix for something that was reported as a
stability problem*, and that, combined with the slab OOB write
could result in the vector that I'm discussing there. The one
without the need to mount a corrupted state.

Incidentally, this also means that if the kernel had actually refused
to fix the issue — which they did for about 5–6 months, only upstreaming
the fix on the same day the CVE was rejected — then the stable 5.4
release would have been affected by that vector
even though the whole thing was kinda dismissed as a non-CVE.

I'll let the reader judge whether this is the right way to
do conservative defense-in-depth or not.

* this was actually the commit that piqued my interest,
because it indicated that something really fishy was going on
about manipulating the B-tree's on disk.
I talked about this for a smaller group of audience, but
I ran into this whole mess through an IoT security evaluation
of sorts by noticing that the company Tuxera used to sell
their HFS+ 'on steroids' solution for Asus, Linksys and a bunch
of manufacturers where the kernel module was essentially just the
upstream driver. Even from the decompiled snippets it was clear that
that driver was somewhat unstable.