Bug 2536747 (CVE-2026-90069)

Summary:	CVE-2026-90069 kernel: crypto: acomp - allocate async request context when cloning
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's cryptographic acceleration (acomp) component. This vulnerability arises when the system attempts to clone a cryptographic request, but insufficient memory is allocated for asynchronous operations. This can lead to an out-of-bounds write, where data is written beyond its intended memory boundary. A local attacker could potentially exploit this memory corruption, leading to a system crash (Denial of Service) or potentially gaining elevated privileges.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-17 19:24:46 UTC

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.

Comment 1 Keith Grant 2026-09-22 16:58:18 UTC

Upstream advisory:
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-90069.mbox