CVE-2026-98418 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Avoid false migration warning for proxy donors
Proxy execution can move a blocked donor's scheduling context to the lock owner's CPU even when the donor is migration-disabled. The donor does not execute there, and its original execution CPU remains recorded in wake_cpu.
set_task_cpu() warns unconditionally for migration-disabled tasks, so a subsequent proxy migration or the wakeup path returning the donor home triggers a false positive: moving a blocked scheduling context does not violate the migration-disabled execution context.
For example, creating a mutex owner on CPU1 and a migration-disabled waiter on CPU0 can trigger the following warning:
proxy_migrate_repro: donor blocking on CPU0 with migration disabled proxy_migrate_repro: donor moved from CPU0 to CPU1 WARNING: kernel/sched/core.c:3389 at set_task_cpu+0x1d3/0x280 ... Call Trace: try_to_wake_up+0x43f/0x780 __mutex_unlock_slowpath+0x330/0x540 owner_fn+0x9f/0xc0 [proxy_migrate_repro]
... proxy_migrate_repro: donor woke on CPU0, task_cpu=0 proxy_migrate_repro: completed
Exclude blocked proxy donors from the warning. The proxy wakeup path restores an executable placement before clearing the blocked state.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The Linux kernel scheduler contains a logic flaw in how it handles migration warnings for tasks that are currently blocked and acting as proxies during lock contention scenarios. Specifically, the function set_task_cpu issues an unconditional warning when attempting to change the CPU affinity of a task marked with migration-disabled flags. This check is designed to prevent legitimate execution contexts from being moved across CPUs while they are actively running or in states where such movement would violate scheduling constraints. However, this validation does not adequately account for proxy donors, which are tasks that block on behalf of other entities during mutex operations and may have their scheduling context temporarily migrated by the scheduler's proxy execution mechanism even when migration is disabled for the donor itself.
In a typical scenario involving proxy execution, a blocked donor task might be moved to a different CPU where the lock owner resides to facilitate faster wake-up or processing. This movement occurs while the donor remains in a blocked state and does not actually execute on that new CPU. The original execution context of the donor is preserved in its wake_cpu field. When the scheduler later attempts to return this proxy task to its home CPU via the wakeup path, it invokes set_task_cpu with migration-disabled flags still active. Because the kernel's warning logic treats any attempt to change the CPU of a migration-disabled task as an error regardless of whether the task is currently executing or blocked, it triggers a false positive warning. This results in unnecessary kernel log noise and potential confusion for developers debugging scheduling issues, despite no actual violation of scheduler integrity occurring since the donor was not running on the intermediate CPU.
The operational impact of this vulnerability includes degraded system observability due to spurious warnings cluttering dmesg outputs and potentially masking real migration-related issues during troubleshooting. While it does not lead to data corruption or privilege escalation, it represents a defect in the scheduler's state validation logic that could mislead administrators into believing there is a deeper scheduling problem when none exists. The issue stems from an overly broad application of migration constraints without considering the specific context where proxy donors are temporarily relocated for efficiency but remain non-executing during that period.
To resolve this, the kernel developers have modified set_task_cpu to exclude blocked proxy donors from triggering the migration warning. This adjustment ensures that when a task is in a blocked state and being managed as part of a proxy execution sequence, the scheduler correctly recognizes that moving its context does not violate migration-disabled constraints because no actual code execution is taking place on the target CPU during this transition. The fix aligns with industry best practices for handling edge cases in concurrent scheduling systems by ensuring validation checks are context-aware rather than purely state-based. This change maps to CWE-20 Improper Input Validation as it addresses a failure to properly validate input conditions relative to task state, and relates to ATT&CK technique T1564 Hidden Elements if one considers the suppression of expected diagnostic output as an obscuring mechanism, though primarily this is classified under standard kernel bug fixes rather than malicious exploitation vectors. The mitigation involves applying the updated scheduler core patch which explicitly checks for blocked proxy donor status before issuing warnings about CPU migration attempts on disabled tasks.