UBUNTU-CVE-2026-90069: High severity ubuntu/linux-hwe-edge vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel crypto: acomp implementation, update acomp_request_clone() to allocate a zeroed clone large enough for the runtime async request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior.
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker needs local, low-privileged access. Exploitation requires a code path that clones an ACOMP_REQUEST_ON_STACK() request while an asynchronous acomp implementation is selected.
Which systems are most likely to encounter the out-of-bounds write?
Systems using an asynchronous compression provider are affected by the vulnerable path. QAT is specifically identified as a provider that can write past the cloned request allocation through acomp_request_ctx().
How can I detect that this issue has occurred?
KASAN can report the condition as a slab out-of-bounds write. The report would result when an asynchronous provider accesses request-context storage that was not allocated in the clone.