---
id: CVE-2026-90069
title: |-
  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
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 implement…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 097c432caaa6d91f87732fe991cb08139e31101a <
    d48197cbd5d3476c7deea644972e9ec510865ec2
  - >-
    Linux >= 097c432caaa6d91f87732fe991cb08139e31101a <
    889fa17a0af09ff93a9166abc82ee7a654faa49b
  - >-
    Linux >= 097c432caaa6d91f87732fe991cb08139e31101a <
    ee440d4fc0d2f15894ab1f64c474a3adbc858880
  - Linux 6.16
published: '2026-09-17'
updated: '2026-09-18'
sourceUpdated: '2026-09-18T18:17:40.710'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90069'
references:
  - url: 'https://git.kernel.org/stable/c/889fa17a0af09ff93a9166abc82ee7a654faa49b'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d48197cbd5d3476c7deea644972e9ec510865ec2'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/ee440d4fc0d2f15894ab1f64c474a3adbc858880'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
epss: 0.00161
epssPercentile: 0.05761
ingestedAt: '2026-09-17T16:21:47.899Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.