CVE-2026-98463 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Derive SCX_RQ_IN_WAKEUP from the core enqueue flags
schedule_deferred_locked() skips scheduling a deferred action while SCX_RQ_IN_WAKEUP is set and relies on the task_woken_scx() call that follows a wakeup enqueue to run it. enqueue_task_scx() sets the flag from the merged enqueue flags, which include the flags stashed for a remote activation. move_remote_task_to_local_dsq() thus sets SCX_RQ_IN_WAKEUP on the destination rq when the moved task was woken up, although no task_woken_scx() follows that activation.
An IMMED insert into a busy destination requests a local reenqueue during that enqueue. The request gets linked but not scheduled and stays pending until an unrelated wakeup or preemption on that CPU runs the deferred actions. The IMMED task sits behind the running task in the meantime. If nothing runs them before the scheduler is disabled, the request outlives the scheduler and points into its freed per-cpu area, which the next scheduler dereferences from run_deferred().
Test the core enqueue flags for the wakeup bit. Only the core's wakeup path is followed by task_woken_scx().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability in question resides within the Linux kernel’s sched_ext subsystem, specifically affecting the logic that manages deferred scheduling actions and remote task activations. The core issue stems from an incorrect derivation of the SCX_RQ_IN_WAKEUP flag during the enqueue process for tasks being moved between runqueues. In normal operation, schedule_deferred_locked is designed to skip executing a deferred action if the SCX_RQ_IN_WAKEUP flag is currently set on the runqueue. This design relies on the assumption that task_woken_scx will be invoked subsequently after a wakeup enqueue event to properly handle and execute these pending actions. However, the implementation of enqueue_task_scx incorrectly sets this flag based on merged enqueue flags which include bits stashed for remote activations rather than strictly reflecting whether the current operation is part of a direct wakeup path.
This logical flaw manifests critically during operations involving move_remote_task_to_local_dsq where a task is moved from one CPU’s runqueue to another while in a woken-up state. In such scenarios, the destination runqueue has SCX_RQ_IN_WAKEUP set due to the merged flags logic, yet no corresponding task_woken_scx call follows this specific activation sequence because it was not triggered by the standard local wakeup path. Consequently, any deferred actions associated with that enqueue are skipped and left pending without being executed immediately or properly scheduled for later execution via the expected mechanism. This creates a gap in the scheduler’s state management where critical scheduling requests remain unprocessed despite appearing to be handled.
The operational impact becomes severe when an IMMED insert into a busy destination runqueue occurs, requesting a local reenqueue during that enqueue operation. The request gets linked into the deferred actions list but is not scheduled for execution due to the aforementioned flag mismanagement and remains pending indefinitely until some unrelated wakeup or preemption event on that CPU inadvertently runs the deferred actions. During this waiting period, the IMMED task sits behind the currently running task in the queue structure. If no such triggering events occur before the scheduler logic is disabled or transitions out of its active state, the request effectively outlives the scheduler instance itself. This leads to a situation where pointers within these pending requests reference freed per-cpu memory areas associated with the previous scheduler context.
When the next scheduler invocation occurs and attempts to dereference run_deferred(), it accesses this stale pointer pointing into freed memory space. This constitutes a use-after-free vulnerability which can lead to kernel crashes, data corruption, or potentially arbitrary code execution depending on how the freed memory is reused by other subsystems. The severity of this issue lies in its potential for remote exploitation if an attacker can influence task scheduling patterns and trigger these specific enqueue conditions under high load or contention scenarios where deferred actions are likely to remain pending longer than usual.
To mitigate this vulnerability, developers must ensure that SCX_RQ_IN_WAKEUP is derived strictly from the core enqueue flags indicating a genuine wakeup path rather than merged flags including remote activation bits. The fix involves testing the specific core enqueue flags for the wakeup bit before setting the flag, ensuring that only tasks following the standard task_woken_scx pathway have this flag set correctly. This guarantees that deferred actions are either executed immediately or properly scheduled via the intended mechanisms without leaving stale pointers in memory structures. System administrators should apply kernel updates containing this patch to prevent potential stability issues and security risks associated with improper scheduler state management during remote task migrations and high-contention enqueue operations.