HIGH
blk-cgroup PolicyActivation UAF
CVE-2026-90326
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI6.3MEDIUM
01Description
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, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() 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 (blkcg_activate_policy): - 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 blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() 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 blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.
02KernelScan AI Analysis
Risk summary
A race condition in the block cgroup subsystem allows a use-after-free when switching IO schedulers concurrently with cgroup deletion. An attacker with root privileges can trigger this to achieve kernel memory corruption, potentially leading to code execution or denial of service. The race window is narrow, making reliable exploitation difficult.
Vulnerability analysis
When switching an IO scheduler on a block device, the kernel allocates per-block-group policy data for all block groups attached to the queue. If one allocation fails, a rollback path releases previously allocated resources — but this rollback can race with concurrent cgroup deletion, which frees the same objects through a separate work queue. The rollback then accesses already-freed memory, causing a use-after-free. Additionally, the destruction path frees policy data before removing the block group from the queue's list, so the activation path can allocate new policy data for a block group already being torn down, leaking memory. The fix extends an existing mutex to cover the entire activation and rollback sequence, serializing it against block-group destruction so the policy data lifecycle stays consistent with list visibility. This vulnerability is reachable locally by any user who can change a block device's IO scheduler via sysfs, which requires root or CAP_SYS_ADMIN in the init namespace.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.1 | 6.1.16 | 6.1.17 | b5dae1cd0d83 |
| 6.12 | — | 6.12.114 | 91062e3a9ed2 |
| 6.18 | — | 6.18.52 | ac34e655dffa |
| 6.2 | 6.2.3 | 6.2.4 | 083b58373463 |
| 6.6 | — | 6.6.160 | 17c18a0df70c |
| 7.2 | — | 7.2.6 | 2cf9f50a38c1 |
| mainline | — | 7.3 | 5313d4d41739 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Affected — no CIP fix yet (latest 6.12.112-cip33) |