CVE-2026-97488 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
qnx4: handle set_blocksize failures
qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the
BUG_ON(offset >= folio_size(folio));
in folio_set_bh on the first __bread_gfp call.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The qnx4 filesystem implementation within the Linux kernel contains a critical flaw related to block size handling during mount operations and subsequent I/O requests. This vulnerability stems from an inadequate check for set_blocksize failures, which leads to improper initialization of buffer heads when the underlying storage device or image specifies a logical block size larger than the system page size. In modern Linux kernels, memory management is heavily optimized around the concept of folios, which are abstractions that can represent one or more contiguous pages. The qnx4 driver relies on traditional buffer_heads to manage data blocks, but these structures have inherent limitations when dealing with sizes exceeding PAGE_SIZE. Specifically, the kernel expects a strict relationship between the offset within a folio and its total size during certain low-level operations.
When an attacker or user attempts to mount a QNX4 filesystem image that has been configured with a block size greater than PAGE_SIZE, the kernel executes the set_blocksize function without verifying if the operation succeeded in aligning properly with page boundaries. This oversight causes subsequent calls to __bread_gfp, which is responsible for reading blocks into memory, to trigger an internal assertion failure. The specific point of failure occurs within folio_set_bh, where a BUG_ON macro checks that the offset does not exceed or equal the folio size. Because the block size mismatch results in offsets that violate this constraint, the kernel triggers a panic condition rather than handling the error gracefully. This constitutes a denial-of-service vulnerability as it causes an immediate system crash upon mounting such a filesystem image.
From a technical classification perspective, this issue aligns with CWE-253, which covers incorrect check of function return value, and CWE-789, which relates to memory corruption due to improper initialization or bounds checking on data structures. The failure to validate the block size configuration allows for an out-of-bounds access scenario within the kernel's internal folio management logic. Although this vulnerability primarily results in a local denial of service through system instability rather than arbitrary code execution, it highlights significant weaknesses in input validation and error handling paths within legacy filesystem drivers. The lack of robustness against non-standard block sizes exposes the core memory management subsystem to crashes that can be triggered by simply accessing maliciously crafted storage media or images.
The operational impact is severe for systems relying on QNX4 support, particularly those involved in embedded environments or forensic analysis where various file system formats are routinely mounted. A successful exploitation requires physical access or elevated privileges to mount the filesystem image, but once executed, it results in an immediate kernel panic and potential data loss if unsaved work exists in memory at the time of the crash. This behavior degrades system reliability and availability, violating core security principles regarding service continuity. Mitigation strategies involve applying upstream kernel patches that enforce strict validation of block sizes before initializing buffer heads. Administrators should ensure their systems are updated with the latest stable kernel versions where this logic has been corrected to handle set_blocksize failures gracefully by rejecting unsupported configurations instead of proceeding to crash-prone code paths. Additionally, restricting mount capabilities for untrusted filesystem types can reduce exposure until patches are deployed.