CVE-2026-80720 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
iomap: add a separate bio_set for iomap_split_ioend
iomap_split_ioend can split bios that already come from iomap_ioend_bioset and thus deadlock when the bioset is exhausted.
Add a separate bio_set to avoid this deadlock.
Christian Brauner <[email protected]> says: Mark iomap_ioend_split_bioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel's file system implementation relies heavily on efficient I/O management to handle data persistence and retrieval operations. A critical component of this subsystem is iomap, which manages mapping between logical file offsets and physical disk blocks. Within this framework, bio structures represent block layer requests that are submitted to the storage driver for processing. To optimize performance and reduce memory allocation overhead, the kernel employs biosets, which are pre-allocated pools of bio descriptors. These sets ensure that high-frequency I/O operations can proceed without blocking on dynamic memory allocations, a common bottleneck in high-throughput scenarios. However, improper management or nesting of these biosets can lead to resource exhaustion conditions that compromise system stability and availability.
A specific deadlock vulnerability was identified within the iomap_split_ioend function, which is responsible for splitting large I/O requests into smaller chunks when they exceed certain size thresholds or encounter boundary constraints. The flaw arises because this function attempts to split bios that were originally allocated from the iomap_ioend_bioset pool. When a bio needs to be split, it requires additional bio structures to represent the resulting fragments. If these new structures are also drawn from the same exhausted bioset, and if the set has reached its limit of available descriptors, the allocation request will block indefinitely waiting for resources that cannot be freed until the original operation completes. This circular dependency creates a classic deadlock scenario where the system hangs because it is waiting for itself to release resources that are locked by the very operation causing the wait.
This vulnerability falls under CWE-834, which covers Exclusion Violations in lock ordering or resource allocation sequences, specifically manifesting as a potential denial of service due to resource exhaustion and deadlock conditions. From an ATT&CK perspective, while this is not directly exploitable for remote code execution by an external attacker without prior access, it represents a local privilege escalation vector if triggered intentionally through crafted file system operations that force deep nesting or high-volume splitting of I/O requests. An authenticated user with write permissions to affected files could potentially trigger the condition under specific load patterns, leading to kernel panics or unresponsive systems, thereby impacting availability and integrity of data processing services running on the host.
The resolution involves introducing a separate bio_set specifically designated for iomap_split_ioend operations. By decoupling the allocation pool used during split operations from the primary bioset, the system ensures that splitting requests do not compete with or block against ongoing I/O completions in the same resource pool. This architectural change breaks the circular dependency chain, allowing splits to proceed even when the main bioset is under pressure. Additionally, as part of this fix, Christian Brauner addressed a sparse warning by marking iomap_ioend_split_bioset as static since it is exclusively used within ioend.c. While primarily a code quality improvement, reducing global symbol visibility minimizes potential namespace collisions and reinforces encapsulation principles in kernel development practices.
Mitigation strategies for organizations running affected Linux kernels involve applying the upstream patch that introduces this dedicated bioset immediately upon availability through standard distribution update channels. System administrators should monitor I/O subsystem logs for signs of latency spikes or hung tasks associated with file system operations, particularly those involving large sequential writes or fragmented storage layouts. In environments where immediate patching is not feasible, workload isolation techniques such as cgroup-based resource limiting can help prevent the exhaustion conditions that trigger this deadlock by throttling excessive concurrent I/O requests from individual processes. Regular kernel updates and adherence to vendor security advisories remain the most effective defense against such low-level concurrency flaws in operating system kernels.