https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-10-02T10:51:42.436538+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/bell-cve-2026-90069 BELL-CVE-2026-90069 2026-10-02T10:51:42.533524+00:00

Affected: Alpaquita:stream: linux-lts

 https://vulnerability.circl.lu/vuln/fkie_cve-2026-90069 fkie_cve-2026-90069 2026-10-02T10:51:42.533596+00:00

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.

 https://vulnerability.circl.lu/vuln/ghsa-83j8-g3f3-xgrf GHSA-83j8-g3f3-xgrf 2026-10-02T10:51:42.533644+00:00

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.

 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1 openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media 2026-10-02T10:51:42.533674+00:00

kernel-devel-7.2.7-1.1 on GA media

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90069 UBUNTU-CVE-2026-90069 2026-10-02T10:51:42.534045+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 120 more

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.