CVE-2026-46102
Linux Kernel 4.9 – 5.10.258
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-46102 is a high-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 40th 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.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-32485
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled…
more
message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.
- 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 development life cycle mandates memory-management practices that reduce missing-release defects.
Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.
Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.
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.