Cloudanix VulnDB

CVE-2026-98418

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A kernel scheduling feature sometimes produced incorrect warning messages when moving certain blocked tasks between processors.

Exploitation
Other
Attacker needs
Other
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw causes set_task_cpu() to emit unconditional warnings for migration-disabled tasks even when proxy execution merely relocates a blocked donor's scheduling context without altering its executable placement or violating migration constraints.

Why it matters to the business

Produces spurious kernel warnings that increase log noise, complicate diagnosis of legitimate scheduling behavior, and raise unnecessary operational overhead on systems relying on proxy execution.

How an attack unfolds

An attacker constructs a scenario with a mutex owner on one CPU and a migration-disabled waiter on another, then triggers unlock paths that invoke proxy migration; this activates the false-positive warning in try_to_wake_up without enabling any privilege escalation or code execution.

How to fix it

Apply the Linux kernel commit that excludes blocked proxy donors from the migration-disabled warning check in sched/core.c; rebuild and deploy updated kernels across affected distributions.

How to confirm the fix worked

After patching, reproduce the proxy_migrate scenario and confirm the warning at set_task_cpu+0x1d3 is no longer emitted; inspect kernel source to verify the added blocked-donor exclusion condition.

Typical attack path

  1. Create mutex owner task on CPU1 and migration-disabled donor on CPU0
  2. Block donor and initiate proxy migration of scheduling context
  3. Trigger __mutex_unlock_slowpath to invoke proxy wakeup
  4. Observe set_task_cpu warning for the blocked donor

How to detect it

Search kernel logs and dmesg for WARNING entries at set_task_cpu involving try_to_wake_up and __mutex_unlock_slowpath; correlate with user-space reproducers that create migration-disabled donors and proxy mutex scenarios.

What your security team should do

  • Prioritize kernel updates on systems using proxy execution or real-time scheduling within the next maintenance window given recent publication and stable low EPSS
  • Add kernel log monitoring for set_task_cpu warnings referencing proxy migration to baseline normal noise levels
  • Review downstream package ecosystems for backported fixes once distribution kernels incorporate the change

The record

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.

Affected packages

Ecosystem Package Introduced Fixed