{"api_version":"1","generated_at":"2026-07-26T14:10:00+00:00","cve":"CVE-2026-64374","urls":{"html":"https://cve.report/CVE-2026-64374","api":"https://cve.report/api/cve/CVE-2026-64374.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-64374","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-64374"},"summary":{"title":"sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-07-25 10:17:20","updated_at":"2026-07-25 10:17:20"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/44aae426dbfd51286f7eb601cfa14bc32164812a","name":"https://git.kernel.org/stable/c/44aae426dbfd51286f7eb601cfa14bc32164812a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d8312a56d9a162e3ec76476aa487e7d20bc602e9","name":"https://git.kernel.org/stable/c/d8312a56d9a162e3ec76476aa487e7d20bc602e9","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/b99f04ae3d200d2f8844aa29145bd18eccbeecde","name":"https://git.kernel.org/stable/c/b99f04ae3d200d2f8844aa29145bd18eccbeecde","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/4bd0da48fbc1dbef6774175129107fbbdd353e26","name":"https://git.kernel.org/stable/c/4bd0da48fbc1dbef6774175129107fbbdd353e26","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/dd29c017aed628076e915fe4cdfb5392fd4c5cab","name":"https://git.kernel.org/stable/c/dd29c017aed628076e915fe4cdfb5392fd4c5cab","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a18f80bf5359238c4f067d691b96af00286fdd89","name":"https://git.kernel.org/stable/c/a18f80bf5359238c4f067d691b96af00286fdd89","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/89237c8fc15d8016a194076e648ccb57d75e65ae","name":"https://git.kernel.org/stable/c/89237c8fc15d8016a194076e648ccb57d75e65ae","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/860aaff72c8446fed5e576249e19952883a18885","name":"https://git.kernel.org/stable/c/860aaff72c8446fed5e576249e19952883a18885","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-64374","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64374","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b b99f04ae3d200d2f8844aa29145bd18eccbeecde git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b d8312a56d9a162e3ec76476aa487e7d20bc602e9 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b 44aae426dbfd51286f7eb601cfa14bc32164812a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b 860aaff72c8446fed5e576249e19952883a18885 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b 89237c8fc15d8016a194076e648ccb57d75e65ae git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b 4bd0da48fbc1dbef6774175129107fbbdd353e26 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b a18f80bf5359238c4f067d691b96af00286fdd89 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b6366f048e0caff28af5335b7af2031266e1b06b dd29c017aed628076e915fe4cdfb5392fd4c5cab git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4.1","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 4.1 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.10.261 5.10.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.15.212 5.15.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.178 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.145 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.96 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.39 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.4 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"64374","cve":"CVE-2026-64374","epss":"0.002200000","percentile":"0.125950000","score_date":"2026-07-25","updated_at":"2026-07-26 00:12:33"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["kernel/sched/features.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"b99f04ae3d200d2f8844aa29145bd18eccbeecde","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"d8312a56d9a162e3ec76476aa487e7d20bc602e9","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"44aae426dbfd51286f7eb601cfa14bc32164812a","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"860aaff72c8446fed5e576249e19952883a18885","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"89237c8fc15d8016a194076e648ccb57d75e65ae","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"4bd0da48fbc1dbef6774175129107fbbdd353e26","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"a18f80bf5359238c4f067d691b96af00286fdd89","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"},{"lessThan":"dd29c017aed628076e915fe4cdfb5392fd4c5cab","status":"affected","version":"b6366f048e0caff28af5335b7af2031266e1b06b","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["kernel/sched/features.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"4.1"},{"lessThan":"4.1","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"5.10.*","status":"unaffected","version":"5.10.261","versionType":"semver"},{"lessThanOrEqual":"5.15.*","status":"unaffected","version":"5.15.212","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.178","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.145","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.96","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.39","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.10.261","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.15.212","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.178","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.145","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.96","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.39","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.4","versionStartIncluding":"4.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2-rc1","versionStartIncluding":"4.1","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled."}],"providerMetadata":{"dateUpdated":"2026-07-25T08:50:26.130Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/b99f04ae3d200d2f8844aa29145bd18eccbeecde"},{"url":"https://git.kernel.org/stable/c/d8312a56d9a162e3ec76476aa487e7d20bc602e9"},{"url":"https://git.kernel.org/stable/c/44aae426dbfd51286f7eb601cfa14bc32164812a"},{"url":"https://git.kernel.org/stable/c/860aaff72c8446fed5e576249e19952883a18885"},{"url":"https://git.kernel.org/stable/c/89237c8fc15d8016a194076e648ccb57d75e65ae"},{"url":"https://git.kernel.org/stable/c/4bd0da48fbc1dbef6774175129107fbbdd353e26"},{"url":"https://git.kernel.org/stable/c/a18f80bf5359238c4f067d691b96af00286fdd89"},{"url":"https://git.kernel.org/stable/c/dd29c017aed628076e915fe4cdfb5392fd4c5cab"}],"title":"sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-64374","datePublished":"2026-07-25T08:50:26.130Z","dateReserved":"2026-07-19T15:36:31.784Z","dateUpdated":"2026-07-25T08:50:26.130Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-25 10:17:20","lastModifiedDate":"2026-07-25 10:17:20","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"64374","Ordinal":"1","Title":"sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT","CVE":"CVE-2026-64374","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"64374","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.","Type":"Description","Title":"sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT"}]}}}