CVE-2026-64073

What it actually does

This is a Linux kernel use-after-free in the irq_work subsystem on PREEMPT_RT kernels. Non-hard irq_work items execute in per-CPU kernel threads, and irq_work_sync() can incorrectly return after the BUSY flag is cleared but before irq_work_single() has finished dereferencing the irq_work structure. A concurrent caller may then free the work object while irq_work_single() still accesses it, creating a race condition that can lead to kernel memory corruption. Because the flaw is in kernel context and the CVSS vector is local, low-complexity, low-privilege, no-user-interaction, successful exploitation could allow a local authenticated attacker to crash the system or potentially escalate privileges to kernel/root level, depending on exploitability in a given kernel build and workload.

Why it matters to the business

Systems running affected Linux kernels with PREEMPT_RT enabled may be exposed to local denial-of-service or privilege-escalation risk. The most likely operational consequence is an unexpected kernel crash, service interruption, or degraded availability on latency-sensitive systems that use real-time kernel configurations. If weaponized for privilege escalation, the issue could allow a user or compromised low-privilege process to gain full control of the host. The vulnerability is not listed in CISA KEV, is not associated with ransomware use, and has a very low EPSS score, so broad internet-scale exploitation is not currently indicated; however, real-time Linux deployments often support critical industrial, telecom, embedded, or low-latency workloads where local reliability and privilege boundaries are important.

How an attack unfolds

An attacker first needs local code execution as a low-privileged user or through a compromised local process on a Linux system running an affected PREEMPT_RT kernel. The attacker then attempts to trigger concurrent irq_work activity and synchronization so that irq_work_single() clears the BUSY flag while still using the work object. In the vulnerable race window, another CPU can observe the work as no longer busy through irq_work_sync(), return to the caller, and allow the object to be freed before irq_work_single() completes. If the freed memory is reused in a controlled way, the stale kernel pointer access may corrupt memory or influence kernel execution; otherwise, exploitation may result in a kernel oops, panic, or system hang. No public exploit maturity is indicated in the provided data, so exploitation should be treated as plausible but not currently known to be commoditized.

How to fix it

Apply the vendor-provided kernel update that includes the irq_work PREEMPT_RT fix. The upstream fix keeps the full irq_work_single() execution inside an RCU read-side critical section and adds synchronize_rcu() in irq_work_sync() after waiting for BUSY to clear, preventing callers from freeing irq_work objects before all readers have finished. Because no exact affected product list or fixed package versions were provided, administrators should check their Linux distribution, appliance, embedded platform, or real-time kernel vendor advisories for CVE-2026-64073 and install the corrected kernel package when available. Reboot into the updated kernel after installation and remove or restrict booting into vulnerable kernels. Where immediate patching is not possible, reduce exposure by limiting local shell access, constraining untrusted workloads, applying least privilege, using container isolation and mandatory access controls where applicable, and disabling PREEMPT_RT kernels in favor of non-RT kernels if operationally acceptable.

How to confirm the fix worked

Confirm whether systems are running PREEMPT_RT kernels by checking kernel version/configuration and distribution packaging information for real-time kernel builds. Validate remediation by confirming the running kernel version after reboot matches a vendor release that includes the fix for CVE-2026-64073, not merely that an updated package is installed on disk. Review vendor changelogs or kernel source patches for the irq_work changes involving run_irq_workd(), irq_work_single(), irq_work_sync(), RCU protection, and synchronize_rcu(). Where source validation is possible, verify the relevant kernel tree contains the added RCU read-side protection around run_irq_workd() processing and the synchronize_rcu() call after rcuwait_wait_event() in irq_work_sync(). For exposure validation, prioritize PREEMPT_RT-enabled hosts and latency-sensitive systems; standard non-RT kernels may not exercise the vulnerable execution path described.

Typical attack path

1. Gain local low-privileged execution on a Linux host running an affected PREEMPT_RT kernel.
2. Determine that the kernel configuration and runtime behavior use non-hard irq_work handled by per-CPU irq_workd kernel threads.
3. Trigger workloads that repeatedly create, synchronize, and free irq_work objects across CPUs.
4. Race irq_work_sync() against irq_work_single() so the BUSY flag is observed as cleared while irq_work_single() still references the work object.
5. Attempt to reclaim or shape the freed kernel memory to turn the stale access into controlled memory corruption.
6. Use the resulting condition to crash the host or, if reliable control is achieved, escalate privileges in kernel context.

How to detect it

Detection should focus on signs of local kernel exploitation attempts or instability because this flaw does not have a network-facing signature. Review kernel logs from journald, syslog, dmesg, crash dumps, and centralized log collectors for oops, panic, general protection fault, page fault, slab corruption, KASAN use-after-free, RCU stalls, or traces involving irq_work, irq_work_single(), irq_work_sync(), run_irq_workd(), rcuwait, or irq_workd per-CPU kernel threads. Correlate kernel faults with local user activity, recently executed binaries, new or unusual scheduled jobs, container workloads, compiler/toolchain use, exploit-like process behavior, and privilege changes. On systems with auditd or EDR, review events around the time of kernel instability for suspicious local execution, attempts to load kernel modules, writes to temporary directories, abnormal use of namespace/container primitives, or unexpected setuid/root process creation. If crash dumps are available, inspect stack traces for irq_work paths and evidence of freed-object access. Absence of these artifacts does not prove the vulnerability was not triggered, because a successful local privilege escalation may leave little kernel-level evidence beyond transient instability or suspicious post-exploitation activity.

• irq_work_single
• irq_work_sync
• run_irq_workd
• irq_workd
• rcuwait_wake_up
• rcuwait_wait_event
• BUG: KASAN: use-after-free
• use-after-free in irq_work_single
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• RCU stall
• slab-use-after-free
• PREEMPT_RT

What your security team should do

• Inventory Linux systems running PREEMPT_RT or real-time kernel packages and prioritize them for review.
• Track Linux distribution, appliance, embedded device, and real-time kernel vendor advisories for fixed kernel releases that address CVE-2026-64073.
• Patch and reboot affected systems into fixed kernels; verify the active kernel after reboot.
• Restrict local access on systems that cannot be patched immediately, especially shared compute, build, edge, industrial, telecom, or embedded Linux platforms.
• Monitor for kernel oops, panic, KASAN, slab, RCU, or irq_work-related errors that may indicate attempted exploitation or reliability impact.
• Ensure vulnerable older kernels are not retained as default boot options after remediation.
• If running untrusted local workloads, strengthen sandboxing with SELinux/AppArmor, seccomp, cgroups, container isolation, and least-privilege service accounts.
• Treat suspicious local privilege escalation activity following kernel instability as potentially related even though no known public exploit maturity or KEV exploitation is indicated.