CVE-2026-90326
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in the Linux kernel can let someone already on the machine crash it or possibly take more control by interfering with how storage policies are managed.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in blk-cgroup during IO scheduler activation allows use-after-free access to freed pd structures and unreachable memory allocations when concurrent blkcg deletion occurs.
Why it matters to the business
May cause Linux kernel crashes, memory corruption, or local privilege escalation on systems performing block device scheduler changes, affecting stability of storage-heavy workloads and increasing breach risk.
How an attack unfolds
Local attacker triggers concurrent blkcg_activate_policy calls while blkcg deletion frees blkg structures, racing through the enomem rollback path to access freed pd memory and potentially corrupt kernel state.
How to fix it
Apply the upstream fix that extends blkcg_mutex coverage around policy rollback and blkg list operations. Update to a patched Linux kernel release containing the blk-cgroup race fix.
How to confirm the fix worked
Confirm the mutex serialization change is present in the running kernel source or distribution package; test scheduler switches under concurrent blkcg deletion workloads for absence of use-after-free reports.
Typical attack path
- Obtain local unprivileged access on a Linux host
- Perform IO scheduler switches on block devices attached to multiple blkgs
- Concurrently delete blkcgs to force blkg destruction during policy activation
- Trigger the race to induce use-after-free and attempt memory corruption or denial of service
How to detect it
Review kernel logs and dmesg for use-after-free warnings or oops in blkcg_activate_policy and blkg_free_workfn during scheduler or cgroup operations; correlate with audit logs showing concurrent blkcg deletions.
What your security team should do
- Apply kernel updates addressing the blk-cgroup race as soon as available from the distribution
- Limit unprivileged local access on systems with frequent block scheduler changes
- Monitor kernel logs for oops or slab corruption involving blkg and pd structures
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|