CVE-2026-90069: crypto: acomp - allocate async request context when cloning
In the Linux kernel, the following vulnerability has been resolved:
crypto: acomp - allocate async request context when cloning
ACOMPREQUESTONSTACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomprequestclone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomprequestctx(). KASAN does report a slab OOB write.
Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization.
Event History
Frequently Asked Questions
Which systems are exposed to the out-of-bounds write?
Systems are exposed when an asynchronous compression (acomp) implementation is selected and a stack-based acomp request is cloned before retrying. Providers such as QAT can then write beyond the cloned allocation through acomp_request_ctx().
What condition triggers the issue?
The issue occurs when ACOMP_REQUEST_ON_STACK() is used, because it reserves storage only for the synchronous fallback, followed by cloning the request for an asynchronous implementation. The clone lacks space for the async provider request context.
How can the issue be detected?
KASAN reports the condition as a slab out-of-bounds write. The reported write occurs when an async provider accesses the request context of the undersized clone.
What is the relevant remediation behavior?
The fix allocates a zeroed clone sized to the runtime acomp request size, rather than the stack-sized source object, and copies only the source bytes that exist. It retains the existing fallback behavior if allocation fails.