Skip to content
Heist/ feed
Back to feed
HighFix available

sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue

Products
Kernel
Affected versions
Not specified
Fixed versions
5.10.261, 5.15.212, 6.1.178, 6.12.96, 6.18.39, 6.6.145, 7.1.4
CVEs
CVE-2026-64374
Confirmed fixed CVEs
Not specified
Updated in this feed
6 Nov 2026, 00:21 UTC · Revision 1

Source evidence

sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT

core-osv · Original source

Published 25 Jul 2026, 08:50 UTC

In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue

osv:CVE-2026-64374

Kernel

Fixed versions: 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4

Complete source record
{
  "id": "a96c9b6135d001530f6582a4a4fe9289b3bcb385b142ddd9257521b782a39e79",
  "url": "https://osv.dev/vulnerability/CVE-2026-64374",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue ",
    "evidence": "osv:CVE-2026-64374",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.10.261",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.15.212",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.178",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.145",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.96",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.39",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.4",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-64374",
      "aliases": [
        "CVE-2026-64374"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "b6366f048e0caff28af5335b7af2031266e1b06b"
                },
                {
                  "fixed": "b99f04ae3d200d2f8844aa29145bd18eccbeecde"
                },
                {
                  "fixed": "d8312a56d9a162e3ec76476aa487e7d20bc602e9"
                },
                {
                  "fixed": "44aae426dbfd51286f7eb601cfa14bc32164812a"
                },
                {
                  "fixed": "860aaff72c8446fed5e576249e19952883a18885"
                },
                {
                  "fixed": "89237c8fc15d8016a194076e648ccb57d75e65ae"
                },
                {
                  "fixed": "4bd0da48fbc1dbef6774175129107fbbdd353e26"
                },
                {
                  "fixed": "a18f80bf5359238c4f067d691b96af00286fdd89"
                },
                {
                  "fixed": "dd29c017aed628076e915fe4cdfb5392fd4c5cab"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64374.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "4.1.0"
                },
                {
                  "fixed": "5.10.261"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "5.15.212"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.178"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.145"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.96"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.39"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.4"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64374.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:45.366373505Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/44aae426dbfd51286f7eb601cfa14bc32164812a",
        "https://git.kernel.org/stable/c/4bd0da48fbc1dbef6774175129107fbbdd353e26",
        "https://git.kernel.org/stable/c/860aaff72c8446fed5e576249e19952883a18885",
        "https://git.kernel.org/stable/c/89237c8fc15d8016a194076e648ccb57d75e65ae",
        "https://git.kernel.org/stable/c/a18f80bf5359238c4f067d691b96af00286fdd89",
        "https://git.kernel.org/stable/c/b99f04ae3d200d2f8844aa29145bd18eccbeecde",
        "https://git.kernel.org/stable/c/d8312a56d9a162e3ec76476aa487e7d20bc602e9",
        "https://git.kernel.org/stable/c/dd29c017aed628076e915fe4cdfb5392fd4c5cab",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64374.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-64374",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64374.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-64374",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 513441,
  "published_at": "2026-07-25T08:50:26.13+00:00"
}