CVE-2026-46081: crypto: acomp - fix wrong pointer stored by acomp_save_req()
In the Linux kernel, the following vulnerability has been resolved:
crypto: acomp - fix wrong pointer stored by acompsavereq()
acompsavereq() stores &req->chain in req->base.data. When acompreqchaindone() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acompreq. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption.
The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomprequestsetsrcdma()). This combination causes cryptoacompcompress() to enter the acompdoreqchain() path, which sets acompreqchaindone() as the completion callback via acompsavereq().
With KASAN enabled, this manifests as a general protection fault in acompreqchaindone():
general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acompreqchaindone+0x15b/0x4e0 Call Trace: <IRQ> qatcompalgcallback+0x5d/0xa0 [intelqat] adfringresponsehandler+0x376/0x8b0 [intelqat] adfresponsehandler+0x60/0x170 [intelqat] taskletactioncommon+0x223/0x820 handlesoftirqs+0x1ab/0x640 </IRQ>
Fix this by storing the request itself in req->base.data instead of &req->chain, so that acompreqchaindone() receives the correct pointer. Simplify acomprestorereq() accordingly to access req->chain directly.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel asynchronous compression (acomp) interface are exposed when an asynchronous hardware implementation completes a request using the DMA virtual address interface. The description specifically identifies the QAT driver as an example.
What conditions are required to trigger the vulnerability?
A compression request must use the DMA virtual address interface, such as through acomp_request_set_src_dma(), and be processed through the asynchronous request-chain path. An asynchronous hardware implementation must then complete that request.
What is the impact if the vulnerable path is reached?
The completion handler treats a pointer to the request's chain member as though it were a pointer to the containing request structure. Subsequent accesses use incorrect offsets, causing memory corruption; with KASAN enabled, the reported manifestation is a general protection fault in acomp_reqchain_done().
How can an administrator identify a likely occurrence?
Look for kernel crashes or KASAN reports naming acomp_reqchain_done(), potentially with qat_comp_alg_callback from the intel_qat driver in the call trace. The supplied example includes a general protection fault and a non-canonical address report.