CVE-2026-46060: crypto: qat - fix IRQ cleanup on 6xxx probe failure
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix IRQ cleanup on 6xxx probe failure
When adfdevup() partially completes and then fails, the IRQ handlers registered during adfisrresourcealloc() are not detached before the MSI-X vectors are released.
Since the device is enabled with pcimenabledevice(), calling pciallocirqvectors() internally registers pcimmsirelease() as a devres action. On probe failure, devres runs pcimmsirelease() which calls pcifreeirqvectors(), tearing down the MSI-X vectors while IRQ handlers (for example 'qat0-bundle0') are still attached. This causes removeprocentry() warnings:
[ 22.163964] removeprocentry: removing non-empty directory 'irq/143', leaking at least 'qat0-bundle0'
Moving the devmaddactionorreset() before adfdevup() does not solve the problem since devres runs in LIFO order and pcimmsirelease(), registered later inside adfdevup(), would still fire before adfdevicedown().
Fix by calling adfdevdown() explicitly when adfdevup() fails, to properly free IRQ handlers before devres releases the MSI-X vectors.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the qat driver probe error path to explicitly call adf_dev_down() when adf_dev_up() partially completes and then fails, ensuring IRQ handlers are detached before devres releases MSI-X vectors.
crypto: qat (6xxx series) driver probe failure handling = call adf_dev_down() when adf_dev_up() fails - Operational
Apply the upstream fix titled 'crypto: qat - fix IRQ cleanup on 6xxx probe failure' to your kernel source (merge the patch into your kernel tree and rebuild or apply the equivalent vendor/kernel update) so that adf_dev_down() is called on adf_dev_up() failure and IRQ handlers are properly freed.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel QAT driver on 6xxx hardware are the relevant exposure set. The issue occurs when device initialization partially succeeds and then fails during probing.
What access does an attacker need?
Exploitation requires local access and low privileges, according to the CVSS vector. No user interaction is required.
How can I tell whether the issue has occurred?
A failed QAT device probe after adf_dev_up() has partially completed can leave IRQ handlers attached while MSI-X vectors are released. Kernel logs may show remove_proc_entry warnings about a non-empty IRQ directory and a leaked handler such as qat0-bundle0.
What does the fix change, and what can be done before it is applied?
The fix explicitly calls adf_dev_down() when adf_dev_up() fails, ensuring IRQ handlers are freed before devres releases MSI-X vectors. If patching is not immediately possible, investigate and remediate failed QAT device probe events rather than allowing the affected initialization failure path to persist.