Hi,
I believe I’ve already shared my main thoughts on this topic on LKML. The discussion between Vyukov and Ts’o is particularly insightful. As I mentioned earlier, it's worth remembering that unprivileged mounting via user namespaces was seriously considered for even block filesystems before, but it was ultimately deemed too difficult—largely due to economic constraints rather than purely technical ones.
That said, there are four points I still feel are worth adding:
1) Maintainers may have missed this, but regardless of the rejected CVE, their CVE automation tooling seems to have picked up the fix as a regular patch. It included an ASAN report with the "out-of-bounds" keyword, so there is now (again) a CVE for my finding:
https://lore.kernel.org/linux-cve-announce/2025050117-CVE-2025-37782-7cc2@gregkh/
NVD may not yet realize it, but CVE-2025-37782 and CVE-2025-0927 refer to the same bug.
2) I haven’t looked into the new report in detail, but I can easily imagine that there are still issues—e.g., bad reads—even without touching extended attributes, just by interacting with the other B-trees. Since the filesystem is no longer orphaned, the new maintainers should be able to assess the report's validity and its actual impact. It probably has less severity, but that remains to be seen.
3) The mismatch in CVE criteria between upstream and downstream distros is a real issue. During the handling of my case, a certain CNA rule was repeatedly cited—without being specified—which led to CVE-2025-0927, initially allocated for Canonical Ubuntu Linux, being reassigned under ownership were originally designed to distribute workload and filter out experience, this creates more confusion than clarity.
4) I think the whole product vs component thing is part of the Cyber Resilience Act anyway, and embedded product manufacturers and entities maintaining distros will likely have to comply with at least the class I requirements, so it probably makes sense to work towards some alignment regarding process until the deadline actually kicks in. Just an idea.
Attila
On 6/3/25 04:59, Solar Designer wrote: Hi,
Muhammed Hüsam Alzeyya, CC'ed here, (kind of) brought an issue in the Linux kernel's HFS+ filesystem implementation to s@k.o and linux-distros at once. This is against both Linux kernel's and linux-distros' current instructions, which ask to "notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security". The message didn't actually get through to linux-distros for a technical reason, but a reply quoting its portion did. I promptly sent a reply to Muhammed (CC'ing linux-distros) to explain the situation and ask a few questions, but got no reply. I saw no further communication on this. (I also checked our server logs, and as far as I can tell there were no further rejected/filtered messages from Muhammed's address, neither to linux-distros nor to my address.) I am now bringing this to oss-security for the sake of transparency and not to make an exception, as well as possibly to have a discussion of the general issues.
There was another issue in the same driver publicized a few months ago, with a lot of detail on its exploitation (and the exploit itself):
https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/
The above post is very lengthy. I'll quote just some pieces below: SSD Advisory - Linux kernel hfsplus slab-out-of-bounds Write March 18, 2025 SSD Secure Disclosure technical team Vulnerability publication
Summary This advisory describes an out-of-bounds write vulnerability in the Linux kernel that achieves local privilege escalation on Ubuntu 22.04 for active user sessions.
Credit An independent security researcher working with SSD Secure Disclosure.
Vendor Response Ubuntu has released the following advisory and fix: https://ubuntu.com/security/CVE-2025-0927
Affected Versions Linux Kernel, up to 6.12.0 Ubuntu 22.04 with Linux Kernel 6.5.0-18-generic
CVE CVE-2025-0927 Attila Szasz <szasza.contact () gmail com> @4ttil4sz1a Exploit for hfs+ slab out of bounds write targeting Linux kernel 6.5 So I'm also CC'ing Attila Szasz here.
The kernel security team ended up rejecting the CVE:
https://lore.kernel.org/linux-cve-announce/2025033057-CVE-2025-0927-1436@gregkh/T/#u Filesystem bugs due to corrupt images are not considered a CVE for any filesystem that is only mountable by CAPSYSADMIN in the initial user namespace. That includes delegated mounting. However, Ubuntu fixed the issue in many of their kernels, with note: While the upstream kernel developers don't consider exploitable corrupted filesystem images to be a security issue, Ubuntu ships with a polkit rule allowing console users to automount removable media, so we do want to fix this issue for our users. An issue here is that "allowing console users to automount removable media" is a high risk, especially if upstream doesn't intend the code to be robust and secure against corrupt or malicious filesystem images. Maybe there should at least be an allow-list of filesystem types, which would be focused on filesystems most commonly used on removable media?
Another issue is the disconnect on what's CVE-worthy between upstream and the distro. This will keep coming up. Maybe a solution for such cases is to assign CVEs against the distro rather than against upstream?
The linux-cve-announce thread above suggests that upstream may assign CVEs to filesystem implementation issues for corruptions that pass fsck. So theoretically a way for a distro to avoid relying on robustness and security of kernel code beyond what upstream cares about would be to force fsck before mounting a filesystem. However, doing that even for filesystems that claim to be clean (as it would be required for security) is impractical. Also, would the CVEs (and eventual fixes) be against (for) the kernel or fsck then?
Anyway, now the current report by Muhammed is for another issue in almost the same place. While Attila's was an out of bounds write, the new one is reported as an out of bounds read. So its security relevance is not obvious even on systems like Ubuntu that expose this code for attack. This depends on what's done with the value read out of bounds.
Below is the portion of Muhammed's message that got to linux-distros: Re: VULNERABILITY REPORT: Out-of-Bounds Read in HFS+ Filesystem's hfsplusbnoderead Function On Sun, May 25, 2025 at 01:30:18PM +0800, Muhammed Hüsam Alzeyya wrote: Summary
A buffer overflow vulnerability exists in the Linux kernel's HFS+ filesystem implementation. Specifically, the vulnerability is located in the hfsplusbnoderead function in fs/hfsplus/bnode.c. When handling an HFS+ filesystem, this vulnerability allows reading beyond the bounds of an allocated memory region. The issue is triggered when the kernel attempts to delete a file on a specially crafted HFS+ filesystem, which can lead to memory corruption, information leakage, and potential privilege escalation. Affected Environments
This vulnerability affects: - Linux kernel 6.15.0-rc2 (confirmed) - Potentially earlier versions that include the HFS+ filesystem implementation - Any system that allows mounting of HFS+ filesystems, especially if untrusted users can provide filesystem images Alexander
On 6/2/25 22:59, Solar Designer wrote: Hi,
Muhammed Hüsam Alzeyya, CC'ed here, (kind of) brought an issue in the Linux kernel's HFS+ filesystem implementation to s@k.o and linux-distros at once. This is against both Linux kernel's and linux-distros' current instructions, which ask to "notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security". The message didn't actually get through to linux-distros for a technical reason, but a reply quoting its portion did. I promptly sent a reply to Muhammed (CC'ing linux-distros) to explain the situation and ask a few questions, but got no reply. I saw no further communication on this. (I also checked our server logs, and as far as I can tell there were no further rejected/filtered messages from Muhammed's address, neither to linux-distros nor to my address.) I am now bringing this to oss-security for the sake of transparency and not to make an exception, as well as possibly to have a discussion of the general issues.
There was another issue in the same driver publicized a few months ago, with a lot of detail on its exploitation (and the exploit itself):
https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/
The above post is very lengthy. I'll quote just some pieces below: SSD Advisory - Linux kernel hfsplus slab-out-of-bounds Write March 18, 2025 SSD Secure Disclosure technical team Vulnerability publication
Summary This advisory describes an out-of-bounds write vulnerability in the Linux kernel that achieves local privilege escalation on Ubuntu 22.04 for active user sessions.
Credit An independent security researcher working with SSD Secure Disclosure.
Vendor Response Ubuntu has released the following advisory and fix: https://ubuntu.com/security/CVE-2025-0927
Affected Versions Linux Kernel, up to 6.12.0 Ubuntu 22.04 with Linux Kernel 6.5.0-18-generic
CVE CVE-2025-0927
Attila Szasz <szasza.contact () gmail com> @4ttil4sz1a Exploit for hfs+ slab out of bounds write targeting Linux kernel 6.5 So I'm also CC'ing Attila Szasz here.
The kernel security team ended up rejecting the CVE:
https://lore.kernel.org/linux-cve-announce/2025033057-CVE-2025-0927-1436@gregkh/T/#u Filesystem bugs due to corrupt images are not considered a CVE for any filesystem that is only mountable by CAPSYSADMIN in the initial user namespace. That includes delegated mounting. If nothing else, this can be used to bypass UEFI Secure Boot. However, Ubuntu fixed the issue in many of their kernels, with note: While the upstream kernel developers don't consider exploitable corrupted filesystem images to be a security issue, Ubuntu ships with a polkit rule allowing console users to automount removable media, so we do want to fix this issue for our users. An issue here is that "allowing console users to automount removable media" is a high risk, especially if upstream doesn't intend the code to be robust and secure against corrupt or malicious filesystem images. Maybe there should at least be an allow-list of filesystem types, which would be focused on filesystems most commonly used on removable media? Which ones would you include? Another issue is the disconnect on what's CVE-worthy between upstream and the distro. This will keep coming up. Maybe a solution for such cases is to assign CVEs against the distro rather than against upstream? This is the only option I can see kernel.org being okay with, but it doesn't solve the underlying problem. kernel.org's view of what is (and is not) a vulnerability in a filesystem is severely out of touch with what distros actually do, and that includes security-conscious distros like ChromiumOS. The linux-cve-announce thread above suggests that upstream may assign CVEs to filesystem implementation issues for corruptions that pass fsck. So theoretically a way for a distro to avoid relying on robustness and security of kernel code beyond what upstream cares about would be to force fsck before mounting a filesystem. However, doing that even for filesystems that claim to be clean (as it would be required for security) is impractical. Also, would the CVEs (and eventual fixes) be against (for) the kernel or fsck then? Why is it impractical? Performance? Anyway, now the current report by Muhammed is for another issue in almost the same place. While Attila's was an out of bounds write, the new one is reported as an out of bounds read. So its security relevance is not obvious even on systems like Ubuntu that expose this code for attack. This depends on what's done with the value read out of bounds.
Below is the portion of Muhammed's message that got to linux-distros: Re: VULNERABILITY REPORT: Out-of-Bounds Read in HFS+ Filesystem's hfsplusbnoderead Function On Sun, May 25, 2025 at 01:30:18PM +0800, Muhammed Hüsam Alzeyya wrote: Summary
A buffer overflow vulnerability exists in the Linux kernel's HFS+ filesystem implementation. Specifically, the vulnerability is located in the hfsplusbnoderead function in fs/hfsplus/bnode.c. When handling an HFS+ filesystem, this vulnerability allows reading beyond the bounds of an allocated memory region. The issue is triggered when the kernel attempts to delete a file on a specially crafted HFS+ filesystem, which can lead to memory corruption, information leakage, and potential privilege escalation.
Affected Environments
This vulnerability affects: - Linux kernel 6.15.0-rc2 (confirmed) - Potentially earlier versions that include the HFS+ filesystem implementation - Any system that allows mounting of HFS+ filesystems, especially if untrusted users can provide filesystem images Alexander There are three filesystems that must be secure against malicious images to avoid very serious problems:
1. FAT32, as this is used by the UEFI System Partition and so must be mounted by every UEFI-based system. 2. F2FS, as this is used by Android for its writable storage. 3. ext4, as this is used by ChromiumOS for its writable storage.
In all three cases, a malicious filesystem image can be used to bypass secure boot. UEFI secure boot is often considered quite weak and I tend to agree with this, but Android and ChromiumOS have very strong verified boot mechanisms and being able to break them is without question worthy of a CVE. ChromeOS Security has confirmed that they do indeed consider "attacker corrupts writable storage to get code execution when the machine reboots" to be in scope for their threat model.
The only way I can think of to fix this issue is not technical, but organizational: somehow ensure that the burden of dealing with these bugs falls onto those who care about them, rather than on overworked filesystem maintainers. Is there any way that this could reasonably be done? Could the Android and ChromeOS security teams triage and fix bugs involving crafted images without the filesystem maintainers having to be involved? Or is the solution for the parties who care about these vulnerabilities to completely reimplement the filesystems in Rust and/or using FUSE? -- Sincerely, Demi Marie Obenour (she/her/hers)