CVE-2026-74731 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Skip sub-disable teardown for never-linked sub-schedulers
A sub-scheduler enable can fail before scx_link_sched() links the sched into the hierarchy, e.g. when the parent is already being disabled, and cleanup still runs the full scx_sub_disable().
That is racy against root disable: drain_descendants() is the only ordering between a sub's disable-time task walk and root disable's all-task teardown, and an unlinked sub is invisible to it. Root's teardown can thus run between the never-linked sub's drain and its walk, exiting every task to no scheduler.
The walk then trips the membership WARN and re-homes the exited tasks onto the dying hierarchy, a use-after-free.
Skip the cgroup ownership reset and the task walk if @sch was never linked, indicated by the empty ->sibling as unlinking only happens later in the same function. The membership WARN remains valid: a linked sub is always waited on by an ancestor's drain.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel scheduler extension subsystem contains a race condition vulnerability within the teardown logic for unlinked sub-schedulers, specifically affecting the scx_sub_disable path. This flaw arises from an inconsistency in how cleanup operations are executed when a sub-scheduler enablement fails before it is successfully linked into the scheduling hierarchy via scx_link_sched(). Under normal operational conditions, a sub-scheduler must be integrated into the parent scheduler's structure to ensure proper lifecycle management and task migration guarantees. However, if the enabling process encounters an error prior to this linkage step, such as when the parent scheduler is already in the process of being disabled, the kernel proceeds with cleanup routines that assume full integration has occurred. This assumption leads to the execution of scx_sub_disable(), which performs a comprehensive teardown sequence including draining descendants and resetting cgroup ownership, despite the sub-scheduler never having been formally attached to the hierarchy.
The core technical flaw lies in the lack of synchronization between this premature cleanup routine and the root scheduler's global task teardown mechanism. The function drain_descendants() serves as the primary ordering point for ensuring that all tasks associated with a sub-scheduler are properly drained before its resources are released. However, because an unlinked sub-scheduler is invisible to the parent hierarchy, it does not participate in this draining process. Consequently, there exists a critical window where the root scheduler's teardown operation can execute between the unlinked sub-schedulers partial drain and its subsequent task walk. During this interval, tasks may be exited or migrated by the root teardown logic without any coordination with the dying sub-scheduler instance. This temporal gap creates a scenario where the sub-scheduler attempts to operate on task structures that are no longer validly associated with it, leading to severe memory safety violations.
This race condition results in a use-after-free vulnerability and triggers kernel warnings related to membership integrity checks. When the unlinked sub-scheduler proceeds with its task walk after the root teardown has altered task states or removed them from their expected scheduling contexts, the code encounters tasks that no longer belong to it according to current hierarchy rules. The kernel detects this inconsistency through a membership warning check designed to catch such anomalies. In response, the system attempts to re-home these exited tasks back onto the dying hierarchy. This reactive measure is insufficient because the underlying memory structures may have already been freed or corrupted by the concurrent teardown operations. The result is potential data corruption, kernel panics, or unpredictable behavior as the scheduler tries to manage resources that are in an undefined state due to the lack of proper synchronization during the failure path of sub-scheduler initialization.
From a threat modeling perspective, this vulnerability aligns with CWE-416, Use After Free, and potentially CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The attack surface is primarily local, requiring an attacker to have the ability to load or manipulate scheduler extensions within the Linux kernel environment. While exploitation typically requires root privileges or access to specific containerization features that allow for custom scheduler configuration, successful exploitation could lead to denial of service through system crashes or potentially privilege escalation if memory corruption can be leveraged to overwrite critical control data structures. The vulnerability highlights a gap in defensive programming practices where error paths do not adequately account for the state assumptions made by subsequent cleanup routines.
To mitigate this risk, developers have implemented a fix that explicitly checks whether the sub-scheduler was ever linked into the hierarchy before proceeding with full teardown operations. This is achieved by verifying if the sibling list pointer is empty, which serves as an indicator that unlinking has not yet occurred or linkage never happened. By skipping the cgroup ownership reset and the associated task walk for these unlinked instances, the kernel avoids interacting with potentially invalid task structures during the race window. This change ensures that only properly linked schedulers undergo the full drain and teardown sequence, maintaining consistency between the scheduler hierarchy state and actual resource management operations. System administrators should ensure their kernels are updated to include this patch, particularly in environments where custom or experimental scheduling policies are deployed via the scheduler extension interface. Regular auditing of kernel logs for membership warnings can also help identify instances where such race conditions might have manifested before a full fix is applied.