Skip to main content

Linux Kernel CVE-2026-64073

| EUVDEUVD-2026-45646 HIGH
Use After Free (CWE-416)
2026-07-19 Linux GHSA-8ffv-2j52-h7h3
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Local access and low privilege needed (AV:L/PR:L); AC:H because exploitation requires winning a tight cross-CPU race on a PREEMPT_RT-only path; UAF yields full C/I/A impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 17:14 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:03 EUVD
CVE Published
Jul 19, 2026 - 15:39 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 19, 2026 - 15:39 cve.org
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT

On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.

After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up().

An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete - causing a use-after-free.

Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.

AnalysisAI

Use-after-free in the Linux kernel's irq_work subsystem allows a local attacker on a PREEMPT_RT (real-time) kernel to corrupt memory by racing irq_work_sync() against irq_work_single(). After the BUSY flag is cleared via atomic_cmpxchg(), the work object is still dereferenced for irq_work_is_hard() and rcuwait_wake_up(), while a concurrent irq_work_sync() caller on another CPU can observe BUSY==0, return, and free the object before those accesses complete. Rated CVSS 7.8 (High); no public exploit identified at time of analysis and EPSS probability is low (0.19%, 8th percentile).

Technical ContextAI

The affected component is irq_work, the kernel mechanism for deferring work to hard-IRQ context. On PREEMPT_RT kernels, non-HARD irq_work does not run in true interrupt context but is instead dispatched to per-CPU kthreads via run_irq_workd(), and irq_work_sync() uses rcuwait() to block until the BUSY bit is cleared. The root cause is a classic use-after-free (CWE-416, though CWE is listed as N/A in the input): the lifetime of the work object is not protected across the window between clearing BUSY and the subsequent dereferences of that object. The upstream fix wraps run_irq_workd() in guard(rcu)() so the whole irq_work_single() execution sits inside an RCU read-side critical section, and adds synchronize_rcu() to irq_work_sync() after rcuwait_wait_event() so the caller waits out an RCU grace period before it may free the work. CPE data (cpe:2.3:a:linux:linux:*) identifies the affected product only generically as the Linux kernel.

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, or 7.1 (or later) as appropriate to your branch - obtained from your distribution or from git.kernel.org/stable (fix commits include 684a78183c54, eef4f71b46a9, 2dc79362302 9, 18c0456ea261, 81b582784518, 91840be8f710). Because the flaw only manifests on PREEMPT_RT kernels, environments running standard non-RT kernels are not affected and need no action beyond normal patching. Where immediate patching of an RT kernel is not possible, the practical compensating control is to restrict local access - this is a local-only bug requiring the ability to run code on the host, so limiting untrusted local users and containers reduces exposure; if the real-time profile is not strictly required, switching that host off PREEMPT_RT eliminates the vulnerable path entirely, at the cost of losing real-time latency guarantees.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-64073 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy