CVE-2026-90326: blk-cgroup: fix race between policy activation and blkg destruction
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix race between policy activation and blkg destruction
When switching an IO scheduler on a block device, blkcgactivatepolicy() allocates blkgpolicydata (pd) for all blkgs attached to the queue. However, blkcgactivatepolicy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues.
The use-after-free occurs in the following race:
T1 (blkcgactivatepolicy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources
T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkgfreeworkfn() - blkg1->pd is freed
T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free
In addition, blkgfreeworkfn() frees pd before removing the blkg from q->blkglist. This allows blkcgactivatepolicy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed.
Fix these races by extending blkcgmutex coverage to serialize blkcgactivatepolicy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Extend blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring blkg_policy_data (pd) lifecycle is synchronized with blkg list visibility and preventing access to freed pd objects.
Event History
Frequently Asked Questions
What combination of activity is required to trigger the race?
The issue involves IO scheduler policy activation on a block-device queue occurring concurrently with deletion of a block cgroup attached to that queue. The use-after-free path additionally involves allocation failure during policy-data setup, followed by rollback.
What are the possible effects of the race?
The rollback path can access policy data after the associated block-group object has been freed, causing a use-after-free. A separate destruction-order race can allocate policy data for an object being destroyed and leave that allocation unreachable, causing a memory leak.
What does the resolved change do to prevent the race?
It extends blkcg_mutex coverage to serialize the relevant block-cgroup policy activation and destruction activity. This prevents policy-data handling from racing with block-group deletion.