CVE-2026-90183: blk-iolatency: clear delay state when freeing policy data
In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: clear delay state when freeing policy data
io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, checkscalechange() scales down its peers, and a peer that reaches queue depth one gets blkcgusedelay() called on it on every further scale-down, even with minlatnsec == 0.
iolatencypdoffline() resets the target through iolatencysetminlatnsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->usedelay set and blkcg->congestioncount elevated with nothing left that can drop it.
blkcgroupcongested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: pagecachesyncra() cuts readahead to a single page, pagecacheasyncra() skips it altogether, and foliothrottleswaprate() takes swapavaillock and schedules a throttle on anonymous folio allocation.
Clear the delay in iolatencypdfree(). By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so checkscalechange() cannot 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
When can the stale throttling condition occur?
It can occur when io.latency throttles a peer cgroup that has no latency target of its own after a sibling misses its target. If that peer is scaled down to queue depth one, it can acquire delay state even though its min_lat_nsec is zero.
Does the impact end when the io.latency policy data is removed?
No. Before the fix, freeing the policy data can leave blkg->use_delay set and blkcg->congestion_count elevated. The cgroup and all of its descendants remain reported as congested for as long as the cgroup exists.
What operational symptoms indicate that a cgroup is affected?
Tasks in the affected cgroup may have readahead reduced to a single page or skipped for asynchronous readahead. Anonymous folio allocation can also schedule swap-rate throttling.