GHSA-R52X-QXPQ-PV5M
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33In 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.
{
"affected": [],
"aliases": [
"CVE-2026-45919"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:06Z",
"severity": null
},
"details": "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": "GHSA-r52x-qxpq-pv5m",
"modified": "2026-05-27T15:33:16Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16ca9f3117e9a294646c897daf08a5ab546c711b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b3c672a66db3de3b40f8a7057864bc1f874ede3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52aeb1e07ec223caf212f036817976c98d2aa250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ad5577b2d4acfd83f03d97a0aece2d18aac5f07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94894c9c477e53bcea052e075c53f89df3d2a33e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f25edc5a20cb52a5abbf25f0724bb4732b81801"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6a73403733e86748421f2eeaf028c85683ef896"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d57d0746276a88ea43a2cc62b849fd8a95e32e41"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.