crypto: acomp - allocate async request context when cloning
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.18.52, 7.2.6
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: crypto: acomp - allocate async request context when cloning ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() 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 acomp_request_ctx(). 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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 097c432caaa6d91f87732fe991cb08139e31101a · fixed in d48197cbd5d3476c7deea644972e9ec510865ec2; From 097c432caaa6d91f87732fe991cb08139e31101a · fixed in 889fa17a0af09ff93a9166abc82ee7a654faa49b; From 097c432caaa6d91f87732fe991cb08139e31101a · fixed in ee440d4fc0d2f15894ab1f64c474a3adbc858880
- Linux Linux
6.16
- KernelLinux
From 6.16.0 · fixed in 6.18.52; From 6.19.0 · fixed in 7.2.6