Description

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 <brauner@kernel.org> 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T08:16:57.810Z",
  "pubdate": "2026-08-28T08:16:57.810Z",
  "executiveSummary": "A resource exhaustion vulnerability exists within the Linux kernel iomap subsystem, specifically concerning the handling of bio_set structures during I/O operations.\nThe vulnerability occurs when iomap_split_ioend attempts to split BIOs using the same bio_set as the original I/O request, leading to potential deadlock conditions if the bio_set becomes exhausted.\nThis flaw affects systems utilizing the iomap framework for storage I/O, such as XFS or other filesystems leveraging this infrastructure.\nThe primary risk is a kernel-level denial-of-service (DoS) resulting from a system hang, as blocked I/O threads prevent further filesystem operations.\nExploitation does not require external network access; it can be triggered locally by processes performing I/O operations that force frequent or complex BIO splitting.\nThe vulnerability is inherent to the kernel's resource management logic and does not require elevated privileges, though a user must be able to initiate specific I/O patterns to trigger the resource depletion.",
  "technicalDetails": "The Linux kernel's iomap infrastructure utilizes a pre-allocated bio_set, iomap_ioend_bioset, to manage BIO structures required for asynchronous I/O completion. In the original implementation, the function iomap_split_ioend reused this shared bio_set to allocate new BIOs when splitting existing ones.\nThe root cause is a resource dependency loop. When iomap_split_ioend consumes the remaining BIOs in the shared pool to complete a split operation, it may be forced to wait for other threads to release BIOs back into that same pool. If those other threads are concurrently waiting on the completion of the current operation—which cannot proceed until the split completes—the system enters a state of circular dependency, resulting in a deadlock.\nThe exploitation flow begins when an I/O request necessitates a split—typically due to filesystem constraints or block layer requirements. As the system reaches high I/O pressure, the iomap_ioend_bioset pool becomes depleted. When iomap_split_ioend attempts to allocate additional BIOs from the same resource pool to facilitate the split, the thread is blocked pending the availability of a free BIO entry.\nIf the threads responsible for freeing BIOs are themselves stalled behind the progress of the original I/O request, the kernel cannot reclaim the resources. This leads to a persistent hang of the affected I/O process and potentially the entire filesystem stack. Because this involves kernel-level data structures, the impact is a system-wide denial-of-service.\nThe vulnerability is resolved by isolating the BIO allocation context for split operations. By introducing a separate, dedicated bio_set for iomap_split_ioend, the kernel ensures that splitting operations are not gated by the same resource constraints as primary I/O submission. This architectural separation prevents the exhaustion of the primary bio_set from stalling the completion path.\nAdditionally, the implementation includes a maintenance fix where iomap_ioend_split_bioset is explicitly declared as static in ioend.c, adhering to kernel coding standards and resolving static analysis warnings regarding internal visibility."
}