FKIE_CVE-2026-45919

Vulnerability from fkie_nvd - Published: 2026-05-27 14:17 - Updated: 2026-05-27 14:48
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/16ca9f3117e9a294646c897daf08a5ab546c711b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3b3c672a66db3de3b40f8a7057864bc1f874ede3
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/52aeb1e07ec223caf212f036817976c98d2aa250
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8ad5577b2d4acfd83f03d97a0aece2d18aac5f07
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/94894c9c477e53bcea052e075c53f89df3d2a33e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9f25edc5a20cb52a5abbf25f0724bb4732b81801
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a6a73403733e86748421f2eeaf028c85683ef896
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d57d0746276a88ea43a2cc62b849fd8a95e32e41
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u003eprio \u003c rq-\u003edonor-\u003eprio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u003erto_loop_next. Even when rd-\u003erto_cpu is set to -1, the mismatch between\nrd-\u003erto_loop and rd-\u003erto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026\u0026 rt_nr_total \u003e 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n         cpu0                      cpu1                    cpu2\n                                pull_rt_task\n                              tell_cpu_to_push\n                 \u003c------------irq_work_queue_on\nrto_push_irq_work_func\n       push_rt_task\n    resched_curr(rq)                                   pull_rt_task\n    rto_next_cpu                                     tell_cpu_to_push\n                      \u003c-------------------------- atomic_inc(rto_loop_next)\nrd-\u003erto_loop != next\n     rto_next_cpu\n   irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios."
    }
  ],
  "id": "CVE-2026-45919",
  "lastModified": "2026-05-27T14:48:03.013",
  "metrics": {},
  "published": "2026-05-27T14:17:06.790",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/16ca9f3117e9a294646c897daf08a5ab546c711b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3b3c672a66db3de3b40f8a7057864bc1f874ede3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/52aeb1e07ec223caf212f036817976c98d2aa250"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8ad5577b2d4acfd83f03d97a0aece2d18aac5f07"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/94894c9c477e53bcea052e075c53f89df3d2a33e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9f25edc5a20cb52a5abbf25f0724bb4732b81801"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a6a73403733e86748421f2eeaf028c85683ef896"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d57d0746276a88ea43a2cc62b849fd8a95e32e41"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.


Detection rules are retrieved from Rulezet.