CyberSecBulletin
CVE-2026-64374NVD status: Modified

Linux: Improper Locking

Published Updated By the CyberSecBulletin desk

CVE-2026-64374 is a high-severity improper locking vulnerability in Linux, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions b99f04ae3d200d2f8844aa29145bd18eccbeecde, d8312a56d9a162e3ec76476aa487e7d20bc602e9, 44aae426dbfd51286f7eb601cfa14bc32164812a as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.39% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to b99f04ae3d200d2f8844aa29145bd18eccbeecde or d8312a56d9a162e3ec76476aa487e7d20bc602e9 or 44aae426dbfd51286f7eb601cfa14bc32164812a or 860aaff72c8446fed5e576249e19952883a18885, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 5.10.261 or 5.15.212 or 6.1.178 or 6.6.145, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinuxb6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, b99f04ae3d200d2f8844aa29145bd18eccbeecde; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, d8312a56d9a162e3ec76476aa487e7d20bc602e9; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, 44aae426dbfd51286f7eb601cfa14bc32164812a; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, 860aaff72c8446fed5e576249e19952883a18885; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, 89237c8fc15d8016a194076e648ccb57d75e65ae; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, 4bd0da48fbc1dbef6774175129107fbbdd353e26; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, a18f80bf5359238c4f067d691b96af00286fdd89; b6366f048e0caff28af5335b7af2031266e1b06b up to, but not including, dd29c017aed628076e915fe4cdfb5392fd4c5cab; and 1 more rangesb99f04ae3d200d2f8844aa29145bd18eccbeecde, d8312a56d9a162e3ec76476aa487e7d20bc602e9, 44aae426dbfd51286f7eb601cfa14bc32164812a, 860aaff72c8446fed5e576249e19952883a18885, 89237c8fc15d8016a194076e648ccb57d75e65ae, 4bd0da48fbc1dbef6774175129107fbbdd353e26
LinuxLinux Kernel4.1 up to, but not including, 5.10.261; 5.11 up to, but not including, 5.15.212; 5.16 up to, but not including, 6.1.178; 6.2 up to, but not including, 6.6.145; 6.7 up to, but not including, 6.12.96; 6.13 up to, but not including, 6.18.39; 6.19 up to, but not including, 7.1.45.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
NoneNo data is disclosed.
Integrity
NoneNothing can be modified.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by CNA.

Official description

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 lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Locking

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

How developers prevent this class of flaw

  • Use industry standard APIs to implement locking mechanism.

More Improper Locking vulnerabilities (CWE-667)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Improper Locking vulnerabilities

Spotted an error? Tell us.