CVE-2026-23350
Linux Kernel 6.19.1 – 6.19.7
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-23350 is a high-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-23350 is a vulnerability in the Linux kernel's DRM/Xe driver, specifically in the exec queue management code. When exec queue creation fails, the code previously skipped the corresponding fini call, which is responsible for removing the queue from the GuC list as part of guc_id allocation. This omission leaves a damaged queue entry in the exec_queue_lookup list, eventually leading to invalid memory references. The issue is classified under CWE-401 (Memory Leak) and has a CVSS v3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
A local attacker with low privileges can exploit this vulnerability due to its low attack complexity and lack of required user interaction. Successful exploitation could result in high impacts to confidentiality, integrity, and availability, such as system crashes or potential arbitrary code execution via the invalid memory references triggered by the persistent damaged queue entry.
Mitigation involves applying the relevant kernel patches from the stable repository. The fixes, cherry-picked from upstream commit 393e5fea6f7d7054abc2c3d97a4cfe8306cd6079, ensure a fini call is made on creation failure to free the guc_id before internal LRCs are freed. This reuses __xe_exec_queue_fini() and modifies xe_lrc_put() to handle NULL parameters safely, as detailed in the commits at https://git.kernel.org/stable/c/99f9b5343cae80eb0dfe050baf6c86d722b3ba2e and https://git.kernel.org/stable/c/fae65b8a4449ae556990efcde8d74bec4adc5925.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-15321
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: drm/xe/queue: Call fini on exec queue creation fail Every call to queue init should have a corresponding fini call. Skipping this would mean skipping removal of the queue from GuC…
more
list (which is part of guc_id allocation). A damaged queue stored in exec_queue_lookup list would lead to invalid memory reference, sooner or later. Call fini to free guc_id. This must be done before any internal LRCs are freed. Since the finalization with this extra call became very similar to __xe_exec_queue_fini(), reuse that. To make this reuse possible, alter xe_lrc_put() so it can survive NULL parameters, like other similar functions. v2: Reuse _xe_exec_queue_fini(). Make xe_lrc_put() aware of NULLs. (cherry picked from commit 393e5fea6f7d7054abc2c3d97a4cfe8306cd6079)
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.
Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.
Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect unreleased memory, providing partial coverage of the weakness.
Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.
Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.