CVE-2026-64438

What it actually does

This is a Linux kernel use-after-free race in the Intel QuickAssist Technology (QAT) driver’s SR-IOV virtual-function to physical-function messaging path. During SR-IOV disablement, the driver can free per-virtual-function state while PF-side response work is still queued or executing. A worker can then dereference freed memory through the intel_qat module, potentially causing kernel memory corruption, kernel panic, or, under favorable conditions, local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems using Intel QAT with SR-IOV enabled may be exposed to host instability or compromise by a local user or workload with access to a QAT virtual function. In virtualized or multi-tenant environments, exploitation could disrupt cryptographic acceleration services, crash hosts, affect hosted workloads, or allow an attacker to break isolation by influencing kernel memory. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no public exploit maturity reported, but the high CVSS impact warrants prompt remediation on systems using affected QAT SR-IOV configurations.

How an attack unfolds

An attacker first needs local code execution or control of a workload that can interact with an Intel QAT virtual function. The attacker repeatedly triggers VF-to-PF messages while also causing or racing SR-IOV teardown on the physical function. In the vulnerable driver, the interrupt path can queue PF response work that retains a raw pointer to per-VF state. If SR-IOV is disabled before queued or in-flight work is stopped, the per-VF state and associated locks can be destroyed while the worker still references them. When the worker later runs, it dereferences freed memory in the kernel. The most reliable outcome is a kernel crash or denial of service; with heap grooming and precise timing, memory corruption may be exploitable for privilege escalation or compromise of the host kernel.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the Intel QAT VF2PF teardown race. The fix gates VF2PF work during teardown, masks interrupts, synchronizes MSI-X interrupt handling, flushes the PF response workqueue, and only then frees per-VF state. If vendor-specific fixed package versions are not available, use the latest security-supported kernel from the Linux distribution or hardware vendor that contains the upstream fix. As interim mitigation, disable Intel QAT SR-IOV where it is not required, avoid exposing QAT virtual functions to untrusted workloads, restrict local administrative or device access that can trigger SR-IOV lifecycle changes, and schedule controlled maintenance windows for QAT driver reloads or SR-IOV reconfiguration.

How to confirm the fix worked

Confirm the running kernel includes the vendor backport or upstream fix for the intel_qat VF2PF teardown race. Validate with package manager metadata, distribution advisories, kernel changelogs, or source inspection for the added VF2PF disable gating and workqueue flush behavior around adf_disable_sriov(). Check whether Intel QAT is present and loaded by looking for the intel_qat module and QAT PCI devices. Confirm whether SR-IOV is enabled by inspecting the relevant PCI device sriov_numvfs value. After patching, perform controlled SR-IOV enable/disable or QAT driver reload testing, if operationally safe, and verify there are no kernel oops, KASAN reports, or workqueue crashes involving qat_pf2vf_resp_wq, adf_iov_send_resp, or adf_disable_sriov().

Typical attack path

1. Gain local execution on a Linux system or guest/workload with access to an Intel QAT SR-IOV virtual function.
2. Generate repeated VF2PF messages through the QAT virtual function interface.
3. Trigger or wait for SR-IOV disablement, device reset, driver unload, host maintenance, or equivalent teardown activity on the physical function.
4. Race queued PF response work against teardown of per-VF state in the intel_qat driver.
5. Cause the queued worker to access freed per-VF memory.
6. Leverage the resulting kernel memory corruption for denial of service, or attempt privilege escalation if exploitation conditions are favorable.

How to detect it

Detection should focus on evidence of attempted or successful race triggering rather than a single network indicator, because exploitation is local and occurs inside the kernel driver. Review kernel logs, persistent journal entries, console logs, kdump/vmcore records, hypervisor event logs, and EDR telemetry for kernel oops, panic, KASAN, or general protection fault messages involving the intel_qat module, QAT PF/VF messaging, SR-IOV disablement, or the qat_pf2vf_resp_wq workqueue. Correlate crashes with recent changes to sriov_numvfs, QAT device resets, driver unload/reload activity, VM or container lifecycle events using QAT virtual functions, and unusual repeated access to QAT devices by local users. On systems with kdump enabled, inspect vmcore backtraces for adf_iov_send_resp, adf_recv_and_handle_vf2pf_msg, adf_gen4_pfvf_send, mutex_lock, process_one_work, and worker_thread. A single crash may be accidental or operational, but repeated QAT-related crashes around SR-IOV teardown are suspicious and should be investigated as potential exploitation or stress testing.

• BUG: KASAN: null-ptr-deref in mutex_lock
• Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat]
• adf_iov_send_resp [intel_qat]
• adf_recv_and_handle_vf2pf_msg
• adf_gen4_pfvf_send
• adf_disable_sriov
• intel_qat
• qat_pf2vf_resp_wq
• process_one_work
• worker_thread
• /sys/bus/pci/devices/*/sriov_numvfs
• BUG: unable to handle kernel NULL pointer dereference
• general protection fault: 0000 [#1]
• Kernel panic - not syncing

What your security team should do

• Identify Linux hosts with Intel QAT hardware, the intel_qat driver loaded, and SR-IOV enabled.
• Prioritize patching hypervisors, accelerator hosts, and any systems exposing QAT virtual functions to containers, guests, or less-trusted workloads.
• Upgrade to a vendor-supported kernel containing the fix; if no fixed package is available, apply the latest distribution security kernel as soon as it is released.
• Temporarily disable QAT SR-IOV or remove QAT VF access from untrusted workloads until patched.
• Restrict who can reload QAT modules, reset QAT devices, alter SR-IOV VF counts, or initiate host maintenance workflows that affect QAT teardown.
• Monitor kernel logs for QAT-related crashes, KASAN reports, workqueue failures, and unexpected host reboots.
• If suspicious crashes are observed, preserve kernel logs, vmcore/kdump artifacts, module versions, and PCI SR-IOV configuration for forensic review.