CVE-2026-43007

What it actually does

This is a local, low-privilege flaw in the Linux kernel QAIC accelerator driver. When a device-side DBC deactivation transaction is received after the owning user process has already exited, the host-side driver can fail to release and resynchronize the DBC resource state. A later user that activates a network may be assigned the same DBC, while the driver still believes it is in use, causing the activation path to wait indefinitely. The primary practical impact is denial of service through hung user processes and leaked accelerator resources until the device is reset, removed, or the host is rebooted.

Why it matters to the business

Systems that rely on the affected Linux QAIC accelerator driver can experience stuck AI/accelerator workloads, reduced accelerator capacity, and operational disruption from jobs that never complete. Because exploitation requires local access and the issue is not in CISA KEV, has no known mature public exploit, and has a very low EPSS score, broad internet-scale exploitation is unlikely; however, shared compute platforms, multi-user Linux servers, and environments exposing accelerator devices to containers or untrusted users should prioritize remediation because one local user or workload can disrupt other accelerator users.

How an attack unfolds

An attacker first obtains local access to a Linux system where the QAIC accelerator driver is present and accessible. The attacker opens or otherwise interacts with the QAIC device interface and triggers activation of a network/DBC. They then cause the owning process to exit, crash, or otherwise disappear before the driver handles the device-originated QAIC_TRANS_DEACTIVATE_FROM_DEV transaction. Because the deactivation is normally handled in the qaic_manage_ioctl() context, the stale deactivation can leave the host driver out of sync with the device’s view of available DBCs. When a subsequent user or workload requests activation and the device reassigns the same DBC, the driver waits for dbc->in_use to become false and the requesting process can hang indefinitely. There are no named threat actors or ransomware campaigns currently associated with this issue.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the fix for handling QAIC_TRANS_DEACTIVATE_FROM_DEV transactions after the owner has gone away. No exact upstream or package-specific fixed versions were provided in the input, so remediation should be based on vendor advisories, kernel changelogs, and backported security updates referencing the QAIC DBC deactivation handling fix. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the qaic driver if the accelerator is not required, restricting access to QAIC device nodes to trusted users and services only, preventing untrusted containers from receiving direct accelerator device access, and using cgroup/device policy or udev permissions to limit use. If systems are already impacted, clearing the stale state may require restarting affected workloads and resetting, removing/rebinding the device, or rebooting the host.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor backport for the QAIC change described as handling DBC deactivation when the owner went away. Check distribution security advisories and package changelogs for references to qaic, DBC deactivation, QAIC_TRANS_DEACTIVATE_FROM_DEV, decode_deactivate(), or qaic_manage_ioctl(). Validate exposure by confirming whether the qaic kernel module is loaded and whether QAIC device nodes are present and accessible to non-administrative users. Functional validation should include a controlled regression test where a QAIC workload is started and terminated during or before deactivation, followed by a second activation attempt; after the fix, the second activation should not hang waiting for the stale DBC state. Also confirm that no long-running processes remain blocked in uninterruptible sleep while using QAIC device interfaces.

Typical attack path

1. Gain local authenticated access to a Linux system with the QAIC accelerator driver enabled and the device node accessible.
2. Open or interact with the QAIC device interface and request accelerator/network activation that allocates a DBC.
3. Cause the owning process to terminate or disappear before the device-originated deactivation transaction is handled by the driver.
4. Leave the host-side DBC state stale while the device considers the DBC available again.
5. Trigger, or wait for another workload to trigger, activation that reuses the same DBC.
6. Cause the new activation path to wait indefinitely, resulting in hung user processes and loss of accelerator availability until reset or reboot.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, workload scheduler logs, container runtime logs, and audit logs for QAIC device access followed by hung or killed processes. Look for processes stuck in uninterruptible sleep while interacting with QAIC devices, kernel blocked-task reports, accelerator activation requests that never complete, and repeated recovery actions such as device reset, module unload/reload, PCI remove/rescan, or host reboot. If auditd or eBPF telemetry is available, search for opens and ioctls against QAIC device nodes and correlate them with abrupt process exits or crashes before deactivation. Kernel stack traces or debug logs referencing qaic_manage_ioctl(), decode_deactivate(), DBC deactivation, or dbc->in_use waits are especially relevant. There are no public threat-actor-specific indicators for this CVE; detection should focus on local abuse patterns and operational artifacts of stale QAIC DBC state.

• qaic
• /dev/qaic
• QAIC_TRANS_DEACTIVATE_FROM_DEV
• QAIC_CONTROL
• decode_deactivate
• qaic_manage_ioctl
• dbc->in_use
• DBC deactivation
• blocked for more than 120 seconds
• uninterruptible sleep
• D state
• hung task
• modprobe -r qaic
• rmmod qaic
• /sys/bus/pci/drivers/qaic/unbind
• /sys/bus/pci/drivers/qaic/bind

What your security team should do

• Inventory Linux hosts that load the qaic driver or expose QAIC accelerator devices to users, services, containers, or batch workloads.
• Prioritize patching shared accelerator hosts, multi-tenant compute nodes, CI/build runners, research clusters, and any environment where untrusted or semi-trusted local users can access accelerator devices.
• Apply vendor kernel updates containing the QAIC DBC deactivation fix; track distribution-specific fixed package versions because none were provided in the source data.
• Until patched, restrict QAIC device node access to trusted service accounts and avoid passing QAIC devices into untrusted containers or virtualized workloads.
• If QAIC acceleration is not required, unload or blacklist the qaic module to remove the vulnerable attack surface.
• Monitor for repeated QAIC-related hangs, blocked tasks, abnormal accelerator activation failures, and abrupt process exits around QAIC usage.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not KEV, handle as targeted local-risk remediation rather than emergency internet-facing incident response unless the environment exposes accelerator devices to untrusted users.