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.
