CVE-2026-98880 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: handle set_blocksize failures
ntfs3 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the
BUG_ON(offset >= folio_size(folio));
in folio_set_bh on the first __bread_gfp call.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The ntfs3 filesystem driver in the Linux kernel contains a critical flaw related to how it manages buffer heads when dealing with block sizes that exceed the system page size. Buffer heads are internal data structures used by the VFS layer and specific filesystem drivers to track metadata associated with disk blocks, such as their state on disk versus memory, lock status, and I/O completion flags. The ntfs3 implementation relies heavily on these buffer heads for its operations. However, there is a fundamental incompatibility when the underlying storage device or filesystem configuration specifies a block size larger than PAGE_SIZE, which is typically 4096 bytes on most modern architectures. This mismatch arises because certain internal kernel functions assume that a single folio, which represents one page of memory, can adequately contain and manage all buffer heads associated with it without exceeding its physical boundaries.
When an attempt is made to mount an NTFS volume where the block size exceeds PAGE_SIZE, the driver invokes __bread_gfp to read data into memory. This function attempts to set up buffer heads for the requested blocks using folio_set_bh. Inside this routine, a BUG_ON macro checks if the offset of the buffer head within the folio is greater than or equal to the folio size. If the block size is larger than PAGE_SIZE, the calculated offset will inevitably exceed the folio's capacity, triggering this assertion failure. In kernel space, hitting a BUG_ON results in an immediate and unhandled panic, causing the entire system to crash rather than gracefully returning an error code to the user-space application attempting the mount operation. This represents a severe stability issue that can lead to denial of service through system instability or data corruption if the crash occurs during critical I/O operations.
From a vulnerability classification perspective, this flaw aligns with CWE-253, which covers incorrect check before performing an action, specifically regarding boundary conditions and size validation failures. The kernel fails to validate whether the block size is compatible with its internal buffer head management structures before proceeding with allocation and mapping routines. Furthermore, in terms of attack vectors, while this is primarily a stability issue triggered by specific configuration parameters rather than malicious input from an external attacker, it can be leveraged for local denial-of-service attacks if an unprivileged user has the ability to trigger mount operations on devices configured with large block sizes or if automated systems attempt to access such storage media. It relates to ATT&CK technique T1496, Resource Hijacking, specifically through resource exhaustion via system crashes, although it is more accurately categorized as a reliability defect exploitable for DoS rather than a traditional privilege escalation path.
The operational impact of this vulnerability is significant because mounting filesystems is often performed by root or privileged services during boot sequences or administrative tasks. A crash at this stage prevents the system from accessing critical data stored on NTFS volumes, which are common in dual-boot environments with Windows systems or when sharing storage across heterogeneous platforms. The lack of graceful error handling means that administrators cannot simply receive a mount failure message; instead, they face kernel panics that require hard resets and potentially complicate forensic analysis if the crash dumps core images for review. This issue affects any deployment where ntfs3 is enabled and interacts with hardware or virtual disks configured with block sizes larger than the architecture's page size, such as 8KB or higher on systems using standard 4KB pages.
To mitigate this vulnerability, it is essential to apply the upstream kernel patch that introduces proper error handling for set_blocksize failures within the ntfs3 driver. The fix involves checking whether the requested block size exceeds PAGE_SIZE before attempting to allocate and initialize buffer heads. If such a condition is detected, the driver should return an appropriate errno value, typically EIO or EINVAL, indicating that the operation cannot be completed due to unsupported parameters, rather than proceeding into code paths that assume compatibility with smaller block sizes. System administrators can also mitigate this risk by ensuring that NTFS volumes are formatted with standard 4KB cluster sizes when used on Linux systems running kernels prior to the patch application. Additionally, monitoring kernel logs for early mount failures and avoiding the use of non-standard large block sizes in mixed-OS environments provides a practical workaround until the software update is deployed across all affected infrastructure components.