CVE-2026-64529

What it actually does

This is a local Linux kernel attack-surface vulnerability in the Intel QuickAssist Technology (QAT) driver. The vulnerable driver exposed an unused character device, commonly associated with qat_adf_ctl, and private IOCTL handlers for QAT device configuration, start/stop, status, and enumeration. Because those IOCTL paths were not part of a supported public user-space API and included dead or little-used kernel code, a local low-privileged user could potentially trigger driver bugs through crafted IOCTL requests. Successful exploitation could result in kernel memory corruption or unsafe device-management behavior, leading to privilege escalation, kernel-level code execution, information disclosure, system crash, or loss of integrity and availability.

Why it matters to the business

The main business risk is that a user or compromised low-privileged workload on a Linux system with the affected QAT driver could escalate to full control of the host. This is most important for shared compute, virtualization hosts, container platforms, cryptographic acceleration nodes, network appliances, storage systems, and any environment where Intel QAT hardware or drivers are enabled. It is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity indicated, so urgency is lower than for widely exploited remote vulnerabilities; however, the high CVSS impact means exposed systems should still be patched during the next appropriate kernel maintenance window, sooner for multi-tenant or high-trust-boundary systems.

How an attack unfolds

An attacker first needs local code execution or an authenticated low-privileged account on a vulnerable Linux system where the QAT kernel driver exposes the legacy control character device. The attacker then interacts with the QAT control device and sends crafted IOCTL requests to the unsupported driver-management paths. If one of the removed code paths mishandles user-supplied data, device identifiers, configuration structures, or lifecycle operations, the attacker may trigger kernel memory corruption, invalid state transitions, or other unsafe behavior. With a reliable exploit, the attacker could escalate from an ordinary user context to root or kernel privileges, disable security controls, access sensitive data, tamper with workloads, or crash the system. There are no named threat actors or public exploitation campaigns tied to this issue in the supplied intelligence.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the QAT driver change removing the unused qat_adf_ctl character device and associated IOCTL interface. Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or kernel vendor advisory as the source of truth for fixed builds. After patching, reboot into the updated kernel and verify that the vulnerable driver interface is no longer present. If immediate patching is not possible, reduce exposure by unloading or blacklisting QAT-related kernel modules where QAT acceleration is not required, disabling QAT hardware in firmware or system configuration where feasible, preventing untrusted users and containers from accessing QAT device nodes, tightening udev permissions and device cgroup policies, and limiting local shell access to affected systems. These mitigations reduce exploitability but should not be treated as a permanent substitute for a fixed kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that the package is installed. Validate with commands such as uname -a, package-manager kernel inventory, and vendor advisory mapping. Check whether QAT support is loaded or available using lsmod, modinfo, lspci, and /sys/bus/pci/drivers/ for Intel QAT devices. On fixed systems, the legacy QAT control character device should not be exposed; check for absence of /dev/qat_adf_ctl or similarly named QAT control nodes and confirm there are no active user-space processes holding them open with lsof or fuser. Review udev rules and container device pass-through settings to ensure QAT control devices are not made available to untrusted workloads. Where possible, run vendor or kernel regression tests for QAT cryptographic/compression acceleration to confirm expected functionality remains after the update.

Typical attack path

1. Gain local access to a vulnerable Linux host through a shell, compromised service account, container escape prerequisite, or other foothold.
2. Confirm that the Intel QAT driver is present and that the legacy QAT control character device or IOCTL interface is accessible.
3. Open the QAT control character device from user space.
4. Send crafted IOCTL requests targeting unsupported QAT configuration, status, enumeration, start, or stop paths.
5. Trigger a kernel bug such as memory corruption, invalid device-state handling, or unsafe data processing.
6. Use the resulting kernel-level primitive to escalate privileges, disclose data, tamper with the host, or cause a denial of service.
7. Maintain access or pivot using the elevated privileges if exploitation succeeds.

How to detect it

To determine whether exploitation may have already occurred, focus on local activity against the QAT control interface and signs of kernel instability or privilege escalation. Review auditd, EDR, syslog, journald, kernel logs, and command history for access to QAT character devices, especially by non-root users or unexpected service accounts. If auditd was configured to monitor device access, search for open, ioctl, chmod, chown, or unusual execution events involving QAT device paths. Review /var/log/kern.log, /var/log/messages, dmesg, and journalctl -k for QAT driver warnings, kernel oopses, general protection faults, NULL pointer dereferences, use-after-free symptoms, WARN_ON traces, AER events, or crashes around times of suspicious local activity. Investigate unexpected privilege changes, new setuid binaries, suspicious kernel module loads, tampering with security agents, unexplained reboots, or processes spawned by low-privileged accounts that later perform root-only actions. There are no exploit-specific public indicators provided, so absence of these artifacts does not prove non-exploitation.

• /dev/qat_adf_ctl
• qat_adf_ctl
• adf_ctl_drv
• adf_cfg_user.h
• adf_dev_status_info
• adf_user_cfg_key_val
• adf_user_cfg_section
• adf_user_cfg_ctl_data
• adf_devmgr_verify_id
• adf_devmgr_get_num_dev
• adf_devmgr_get_dev_by_id
• adf_get_vf_real_id
• adf_cfg_del_all

What your security team should do

• Inventory Linux systems with Intel QAT hardware, QAT kernel modules, or QAT device nodes; prioritize shared, multi-tenant, virtualization, container, cryptographic acceleration, and internet-facing service hosts.
• Patch affected systems with vendor-provided fixed kernels and reboot into the updated kernel; prioritize high-value and multi-user systems even though EPSS is low and KEV status is false.
• If patching is delayed, remove untrusted access to QAT device nodes, restrict device pass-through into containers and virtualized workloads, and unload or blacklist QAT modules where not operationally required.
• Search endpoint and audit logs for unusual access to QAT control devices by non-administrative users or unexpected processes.
• Add detections for attempts to open or issue IOCTLs against legacy QAT control devices, especially from shells, scripting runtimes, compilers, exploit staging directories, or service accounts.
• Ensure kernel crash, auditd, and EDR telemetry are retained long enough to investigate possible local privilege-escalation attempts.
• Monitor Linux distribution and appliance vendor advisories for the exact fixed versions applicable to deployed kernels.