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 acomp_save_req()
acomp_save_req() stores &req->chain in req->base.data. When
acomp_reqchain_done() is invoked on asynchronous completion, it receives
&req->chain as the data argument but casts it directly to struct
acomp_req. 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. acomp_request_set_src_dma()). This combination causes
crypto_acomp_compress() to enter the acomp_do_req_chain() path, which
sets acomp_reqchain_done() as the completion callback via
acomp_save_req().
With KASAN enabled, this manifests as a general protection fault in
acomp_reqchain_done():
general protection fault, probably for non-canonical address 0xe000040000000000
KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]
RIP: 0010:acomp_reqchain_done+0x15b/0x4e0
Call Trace:
<IRQ>
qat_comp_alg_callback+0x5d/0xa0 [intel_qat]
adf_ring_response_handler+0x376/0x8b0 [intel_qat]
adf_response_handler+0x60/0x170 [intel_qat]
tasklet_action_common+0x223/0x820
handle_softirqs+0x1ab/0x640
</IRQ>
Fix this by storing the request itself in req->base.data instead of
&req->chain, so that acomp_reqchain_done() receives the correct pointer.
Simplify acomp_restore_req() accordingly to access req->chain directly.
Security readout for executives and security teams
Plain-English summary
A Linux kernel pointer-handling error can corrupt memory during certain asynchronous hardware compression operations. On exposed systems, successful abuse could affect confidentiality, integrity, and availability, while accidental triggering may cause kernel crashes. The vulnerable path requires a specific combination of asynchronous compression hardware and the DMA virtual-address interface.
Executive priority
Treat this as a high-priority kernel update for systems using Intel QAT or similar asynchronous compression. Expedite exposure checks across Linux fleets and patch confirmed systems. Kernel crashes or corruption indicators on relevant hosts should trigger immediate technical investigation; the supplied sources do not establish active exploitation.
Technical view
acomp_save_req() stored the address of req->chain in req->base.data, but acomp_reqchain_done() treated that address as the enclosing acomp_req object. Subsequent accesses used incorrect offsets and corrupted memory. The path is triggered when asynchronous implementations such as Intel QAT complete compression requests using the DMA virtual-address interface. The fix stores the request pointer itself.
Likely exposure
Exposure is most likely on affected Linux kernels using Intel QAT or comparable asynchronous hardware compression with the DMA virtual-address interface. The supplied version entries are ambiguous and include 6.16, 0, 6.18.27, 7.0.4, and 7.1; determine applicability through distribution advisories and backport status.
Exploitation context
No active exploitation evidence is provided, and the bundle marks KEV as false. CVSS classifies the issue as local, low-complexity, requiring low privileges and no user interaction. Practical abuse likely requires access to the specific asynchronous compression and DMA request path. Public exploit availability is not established by these sources.
Researcher notes
The reported KASAN general-protection fault demonstrates an invalid-offset memory access, not exploitation. The correction changes req->base.data from &req->chain to req and simplifies restoration to access req->chain directly. Exact vulnerable release boundaries and downstream backport coverage remain unclear from the supplied affected-version data.
Mitigation direction
Apply a vendor kernel update containing the applicable cited stable fix.
Confirm distribution backports rather than relying only on the displayed kernel version.
If no update is available, obtain vendor-specific mitigation guidance.
Prioritize systems using Intel QAT or other asynchronous hardware compression.
Validation and detection
Inventory running kernel builds and compare them with vendor advisories and backported fixes.
Verify the installed kernel contains an applicable cited commit or equivalent patch.
Identify active asynchronous compression drivers, including Intel QAT, and DMA-interface usage.
Review kernel logs for acomp_reqchain_done faults, KASAN reports, or unexplained crashes.
Regression-test hardware compression workloads after updating.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46081 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.