CVE-2026-90182: blk-iocost: clear delay state when freeing policy data
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: clear delay state when freeing policy data
iocgkickdelay() turns sufficiently large debt into an explicit block-cgroup delay with blkcgsetdelay(), setting blkg->usedelay to -1 and incrementing blkcg->congestioncount. Clearing it again depends on iocgkickdelay() running from the period timer, the waitq timer or the issue path.
iocpdfree() removes the iocg from activeiocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for the rest of its life.
blkcgroupcongested() then returns true for every task in that cgroup and its descendants: pagecachesyncra() cuts readahead to a single page, pagecacheasyncra() skips it altogether, and foliothrottleswaprate() takes swapavaillock and schedules a throttle on anonymous folio allocation.
Clear it explicitly, after the list removal and the synchronous hrtimercancel() so that neither timer processing nor an I/O path can re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.
Affected Software
Event History
Frequently Asked Questions
Which workloads are affected by the lingering congestion state?
Tasks in the affected block cgroup and all of its descendant cgroups are affected. The condition occurs when sufficiently large I/O cost debt has created an explicit block-cgroup delay and the policy data is then freed before a timer or I/O path can clear that delay.
What operational symptoms can indicate that a cgroup remains incorrectly congested?
Synchronous page-cache readahead is reduced to one page, asynchronous readahead is skipped, and anonymous folio allocation can be throttled for swap-rate control. These behaviors persist for the lifetime of the affected block cgroup once its congestion state is left set.
What clears the affected state in the resolved implementation?
The delay state is explicitly cleared during policy-data cleanup, after removal from the active I/O cgroup list and synchronous cancellation of the wait-queue timer. This prevents timer processing or I/O activity from re-arming the delay during cleanup.