CVE-2026-90326 in Linux
Summary
by MITRE • 09/17/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel block layer contains a concurrency vulnerability within the block cgroup subsystem that arises during the activation of I/O scheduling policies on block devices. This issue specifically affects the interaction between blkcg_activate_policy and the concurrent deletion of block cgroups, leading to critical memory safety violations including use-after-free conditions and resource leaks. The root cause lies in insufficient synchronization mechanisms when managing the lifecycle of blkg policy data structures relative to their visibility within the queue's list of attached control groups.
When an administrator switches or activates an I/O scheduler on a specific block device, the kernel invokes blkcg_activate_policy to allocate per-blkgroup policy data for all currently attached block cgroups. This allocation process is not atomic with respect to concurrent structural changes in the system state. If a block cgroup deletion occurs simultaneously during this window, the kernel may attempt to access memory that has already been released by another thread handling the destruction of that control group structure.
The primary technical flaw manifests as a use-after-free vulnerability through a specific race condition sequence. In one execution path, the activation routine successfully allocates policy data for an initial block cgroup but fails during allocation for a subsequent one due to memory constraints. This triggers a rollback mechanism intended to release resources allocated so far. However, if another thread concurrently deletes that first block cgroup and frees its associated blkg structure via the asynchronous work function blkg_free_workfn, the policy data pointer becomes dangling. When the rollback path subsequently attempts to access fields within this freed memory region, such as checking online status flags, it triggers undefined behavior characteristic of use-after-free exploits.
A secondary aspect of this vulnerability involves a logic error in the destruction sequence that facilitates resource leaks and potential further corruption. The blkg_free_workfn function frees the policy data before removing the block group from the queue's list of attached groups. This ordering allows the activation routine to allocate new policy data for a block group that is already marked for deletion but not yet removed from the active list. Consequently, when the destruction process finally completes and attempts to free the structure again or access it, the newly allocated memory becomes unreachable because no valid references remain in the system state, resulting in a persistent memory leak.
From an industry standards perspective, this vulnerability aligns with CWE-416 Use After Free, which describes accessing freed memory leading to unpredictable behavior that can be exploited for code execution or denial of service. Additionally, it relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition stems from inadequate locking around shared data structures during state transitions. In terms of ATT&CK mapping, this type of kernel-level memory corruption could potentially facilitate privilege escalation if an attacker can trigger the specific timing window through local access to block devices and cgroup configurations, although exploitation typically requires significant control over system scheduling and device attachment states.
The operational impact of this vulnerability includes potential kernel panics leading to denial of service for systems relying on dynamic I/O scheduler changes or frequent block group modifications. In more severe scenarios involving crafted memory layouts, it could allow local attackers to execute arbitrary code with kernel privileges by manipulating the freed heap chunks during the race window. The presence of memory leaks also contributes to gradual resource exhaustion over time in environments where such operations are performed frequently.
To mitigate this vulnerability, system administrators should ensure that their Linux kernels are updated to versions containing the fix for blk-cgroup policy activation races. This involves patching the block layer synchronization logic to extend the coverage of the blkcg mutex. By serializing access between the rollback path of policy activation and the destruction work functions, the kernel ensures that the lifecycle of policy data is strictly synchronized with the visibility status of block groups in the queue list. Until patches are applied, limiting dynamic changes to I/O schedulers on active devices and avoiding concurrent cgroup deletions during scheduler operations can reduce exposure risk.