CVE-2026-98872 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
freevxfs: don't BUG() on unknown typed-extent type
vxfs_bmap_typed() handles four typed-extent types and calls BUG() in its default case, so an on-disk typed extent with any other type value crashes the kernel. It is reachable from ioctl(FIBMAP) on a regular file:
kernel BUG at fs/freevxfs/vxfs_bmap.c:230! RIP: vxfs_bmap_typed fs/freevxfs/vxfs_bmap.c:230 [inline]
vxfs_bmap1+0x128a/0x12d0 fs/freevxfs/vxfs_bmap.c:257
Replace the BUG() with WARN_ON_ONCE() and return 0 -- the value vxfs_bmap_typed() already returns on failure (and from the DEV4 case above); vxfs_getblk() maps 0 to -EIO, so the ioctl fails cleanly.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's VXFS filesystem driver contained a critical stability flaw within its block mapping logic that could lead to an immediate system crash when processing malformed or unexpected on-disk data structures. Specifically, the function vxfs_bmap_typed in fs/freevxfs/vxfs_bmap.c was designed to handle four specific typed-extent types but relied on a BUG() macro for any other value encountered in its default case. This design choice meant that if an attacker could influence or provide access to a VXFS volume containing a file with a typed extent of an unrecognized type, the kernel would trigger a fatal bug check and halt execution. The vulnerability is particularly concerning because it can be triggered through standard user-space interactions, specifically via the ioctl(FIBMAP) system call on regular files within the mounted filesystem. This accessibility lowers the barrier for exploitation significantly compared to vulnerabilities requiring root privileges or physical access to hardware configuration.
From a technical perspective, the issue stems from insufficient input validation and error handling robustness in the kernel's file mapping subsystem. When vxfs_bmap_typed encounters an unknown extent type, it does not gracefully degrade or return an appropriate error code; instead, it invokes BUG(), which is intended for unrecoverable internal errors rather than malformed external data. This results in a Denial of Service condition where the entire operating system becomes unresponsive due to a kernel panic. The fix replaces the BUG() call with WARN_ON_ONCE() and ensures the function returns zero upon encountering such unknown types. Since vxfs_getblk maps a return value of zero to -EIO, the ioctl operation fails cleanly with an input/output error rather than crashing the host system. This change aligns the driver's behavior with standard kernel practices where unexpected external data should result in graceful failure at the application layer rather than catastrophic system-wide failure.
This vulnerability is classified under CWE-617: Reachable Assertion, as it involves a reachable assertion that causes a denial of service when triggered by specific input conditions. In terms of attack vectors and tactics, this aligns with ATT&CK technique T1499: Endpoint Denial of Service, where an adversary aims to disrupt the availability of system resources. The ability to trigger this via ioctl(FIBMAP) suggests that any user account with read or execute permissions on a VXFS-mounted volume could potentially exploit this flaw if they can craft or manipulate files containing the specific malformed extent type. This highlights the importance of treating all filesystem data as untrusted, even when it originates from seemingly benign sources within the same system boundary.
Mitigation strategies for this vulnerability primarily involve applying the kernel patch that updates the vxfs_bmap_typed function to handle unknown types gracefully. System administrators should ensure their Linux distributions are updated with the latest stable kernel versions containing this fix. For environments where immediate patching is not feasible, restricting access to VXFS-mounted volumes and limiting user privileges on files within those filesystems can reduce the attack surface. Additionally, monitoring for unusual system logs indicating kernel warnings or panics related to vxfs_bmap.c can help in detecting potential exploitation attempts before they result in a full outage. The resolution demonstrates the critical need for defensive programming practices in kernel development, ensuring that external data inputs are validated and handled with appropriate error codes rather than causing fatal exceptions.