Linux kernel iomap: ioend splitting draws from its own exhausted bio_set and deadlocks writeback

CVE-2026-80720Kernel, userspace & hypervisorcurated

Impact

iomap_split_ioend() split bios that were themselves allocated from iomap_ioend_bioset, so under mempool exhaustion the split waits on a reserve that only completing I/O can replenish - a classic writeback deadlock. When it hits, writeback on an iomap filesystem (XFS and friends, particularly on zoned or split-prone devices) stops making progress and the tasks are stuck in uninterruptible sleep; the node cannot be drained gracefully and needs a reboot. On a GPU node that means killing whatever training or serving work holds the GPUs, since the filesystem hang usually takes the checkpoint and dataset paths with it. The kernel CNA scored this network-reachable, but the practical trigger is memory pressure during heavy writeback rather than a remote packet - treat it as an availability bug on busy storage-heavy nodes.

Who can reach it

Local workload generating enough concurrent writeback to exhaust the iomap ioend bioset; no authentication boundary is crossed, and any tenant able to write heavily to an affected filesystem can create the pressure.

What to do

Update to a stable kernel carrying the linked commits, which add a dedicated iomap_ioend_split_bioset, and reboot each affected node. There is no runtime tunable that removes the shared-mempool dependency; reducing writeback concurrency only lowers the odds. The record names no fixed release beyond the stable commits.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80720 https://git.kernel.org/stable/c/4a869be56e9f6ce7462abcf324ebdefc5de051be https://git.kernel.org/stable/c/c679ce3be6cb63763d68ab9b5d9d73ddc0a40762 https://git.kernel.org/stable/c/cfc686a1174aa904dcad9b9a7c5e46b484d27e4e

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.