CVE-2026-98087: Software Security Vulnerability Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-4fqw-hmjf-w2gv",
  "modified" : "2026-09-25T12:31:36Z",
  "published" : "2026-09-25T12:31:36Z",
  "aliases" : [ "CVE-2026-98087" ],
  "details" : "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt,dl: Skip migrate-disabled tasks when picking a push candidate\n\nA migrate_disable()'d RT task cannot be moved to another CPU, but the\nscheduler still keeps such a task on that CPU's pushable list\n(rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded\n(rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as\nhaving a task to move away, and keeps trying to move the task, but the\npush can never succeed. When the head is pinned, push_rt_task() does not\ngive up either. It falls back to pushing rq->curr instead, using the\nper-CPU stopper, as added by commit a7c81556ec4d (\"sched: Fix\nmigrate_disable() vs rt/dl balancing\").\n\nThe CPU spends tens of milliseconds in this retry loop. The core is\nisolated for real-time work, but during the loop nearly half of its time\nis consumed by pushes that cannot succeed.\n\nAn ftrace capture of the affected CPU, with sched_switch enabled and\ncommit 94894c9c477e (\"sched/rt: Skip currently executing CPU in\nrto_next_cpu()\") applied, shows where the CPU time went. Two SCHED_FIFO\ntasks at equal priority shared the CPU, taskA migrate_disable()'d and\nqueued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of\nCPU. The other 37 ms went to the stopper thread.\n\nThe scheduler kept trying to push taskA, the pinned head of the pushable\nlist, fell back to pushing taskB instead, and woke the stopper 5204\ntimes. Every one of those pushes failed and no task was moved. taskA\nstayed runnable and queued the whole time, and never ran.\n\nPushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq\nlock to take the target rq lock, then checks again with\n\"task != pick_next_pushable_task(rq)\".\n\nThe task being pushed is taskB, but the pick returns taskA, the head of\nthe pushable list. taskB is rq->curr, and set_next_task_rt() removes the\nrunning task from that list, so taskB can never be the head. The check\nexpects a candidate taken from the pushable list, but the fallback\npushes rq->curr, which is never on that list. So the check fails every\ntime.\n\n   .--> push-IPI arrives\n   |          |\n   |          v\n   |     pushable head = taskA   ->  pinned, cannot be pushed\n   |          |\n   |          v\n   |     so push taskB instead   ->  wake migration/N, a stop-class\n   |          |                      thread, so it preempts taskB\n   |          v\n   |     re-check compares taskB against the pushable head,\n   |     which is still taskA                        ->  give up\n   |          |\n   |          v\n   |     nothing moved, taskA still queued, rq still overloaded\n   |          |\n   '----------'\n         repeats every ~17 us, 5204 times, for 89 ms\n\n   The loop cannot stop itself. Every round leaves the runqueue\n   exactly as it was, so the next push-IPI does the same thing. In\n   the capture it ended only when taskB went to sleep on its own.\n   taskA was then picked locally and left the pushable list.\n\n   CPU time per task in the window, from sched_switch:\n\n     taskB         51.95 ms   real work\n     migration/N   37.18 ms   nothing moved\n     taskA          0.00 ms   queued the whole time, never picked\n     idle           0.01 ms\n\n   Counts over the same window:\n\n      7667  push-IPIs handled on this CPU\n     17481  pick_next_pushable_task() returned taskA, still pinned\n      5204  find_lock_lowest_rq() gave up on the re-check\n         1  push that actually completed\n         0  migrations of taskA\n\n   The CPU times and the window length come from the standard\n   sched_switch tracepoint. The counts needed tracepoints added inside\n   the RT balancer for this investigation.\n\nThe self-IPI path is closed by the rto_next_cpu() fix above, and that\npart works. But the runqueue is still marked overloaded, because the\npinned task is still advertised as pushable. Other CPUs now send the\npush-IPIs during their own RT balancing, and the same loop runs again.\nClosing the self-IPI path did not stop a pinn\n---truncated---",
  "severity" : [ ],
  "affected" : [ ],
  "references" : [ {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-98087"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/755476d7ba92a1f3fe2a376c515d710bc6baebc3"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/b0c6f947057751ab4d30ccf8095cd19804fb97fa"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/dae5c0292080dd7b9c7d784268dcf443f1f3d15e"
  } ],
  "database_specific" : {
    "cwe_ids" : [ ],
    "severity" : null,
    "github_reviewed" : false,
    "github_reviewed_at" : null,
    "nvd_published_at" : "2026-09-25T11:17:38Z"
  }
}