FKIE_CVE-2026-98087

Vulnerability from fkie_nvd - Published: 2026-09-25 11:17 - Updated: 2026-09-25 11:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved: sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran. Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing. In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA, still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint. The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinn ---truncated---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/755476d7ba92a1f3fe2a376c515d710bc6baebc3
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b0c6f947057751ab4d30ccf8095cd19804fb97fa
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/dae5c0292080dd7b9c7d784268dcf443f1f3d15e
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/deadline.c",
            "kernel/sched/rt.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "755476d7ba92a1f3fe2a376c515d710bc6baebc3",
              "status": "affected",
              "version": "a7c81556ec4d341dfdbf2cc478ead89d73e474a7",
              "versionType": "git"
            },
            {
              "lessThan": "b0c6f947057751ab4d30ccf8095cd19804fb97fa",
              "status": "affected",
              "version": "a7c81556ec4d341dfdbf2cc478ead89d73e474a7",
              "versionType": "git"
            },
            {
              "lessThan": "dae5c0292080dd7b9c7d784268dcf443f1f3d15e",
              "status": "affected",
              "version": "a7c81556ec4d341dfdbf2cc478ead89d73e474a7",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/deadline.c",
            "kernel/sched/rt.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.11"
            },
            {
              "lessThan": "5.11",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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()\u0027d RT task cannot be moved to another CPU, but the\nscheduler still keeps such a task on that CPU\u0027s pushable list\n(rq-\u003ert.pushable_tasks) and still marks the runqueue RT-overloaded\n(rq-\u003ert.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-\u003ecurr 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()\u0027d and\nqueued, taskB as rq-\u003ecurr. 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-\u003ecurr, 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-\u003ecurr, which is never on that list. So the check fails every\ntime.\n\n   .--\u003e push-IPI arrives\n   |          |\n   |          v\n   |     pushable head = taskA   -\u003e  pinned, cannot be pushed\n   |          |\n   |          v\n   |     so push taskB instead   -\u003e  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                        -\u003e  give up\n   |          |\n   |          v\n   |     nothing moved, taskA still queued, rq still overloaded\n   |          |\n   \u0027----------\u0027\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---"
    }
  ],
  "id": "CVE-2026-98087",
  "lastModified": "2026-09-25T11:17:38.343",
  "metrics": {},
  "published": "2026-09-25T11:17:38.343",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/755476d7ba92a1f3fe2a376c515d710bc6baebc3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b0c6f947057751ab4d30ccf8095cd19804fb97fa"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/dae5c0292080dd7b9c7d784268dcf443f1f3d15e"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.