Cyber Resilience

CVE-2026-45885

Memory Safety in Linux Kernel 4.13 – 5.10.252

Published
27 May 2026
Modified
25 June 2026
Patch / advisory
CVSS Score v3.1 7.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score 0.0016 6th percentile
Risk Priority 55 floored blend · peak EPSS

Summary

CVE-2026-45885 is a high-severity Use After Free (CWE-416) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 6th 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

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be…

more

deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise TechniquesAI

T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
Why these techniques?

Kernel UAF race leads directly to system crash (DoS) via triggered interrupt during power_supply unregistration.

Confidence: MEDIUM · MITRE ATT&CK Enterprise v19.0

CVEs Like This One

CVE-2024-56772Same product: Linux Linux Kernel
CVE-2023-6039Same product: Linux Linux Kernel
CVE-2026-43447Same product: Linux Linux Kernel
CVE-2026-31715Same product: Linux Linux Kernel
CVE-2026-23351Same product: Linux Linux Kernel
CVE-2026-45879Same product: Linux Linux Kernel
CVE-2026-31511Same product: Linux Linux Kernel
CVE-2026-45906Same product: Linux Linux Kernel
CVE-2026-31419Same product: Linux Linux Kernel
CVE-2026-45938Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
4.13 — 5.10.252 · 5.11 — 5.15.202 · 5.16 — 6.1.165

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)
  • SA-11 Developer Testing and Evaluation
  • SA-15 Development Process, Standards, and Tools
  • SI-16 Memory Protection
Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)
  • 3 hardening rules · 3 OS baselines
Validate
Prove the fix (OWASP ASVS)
  • V1.4.3

Mitigating Controls (NIST 800-53 r5) AI

prevent

Developer testing and evaluation (including concurrency and error-injection tests) would have detected the IRQ-vs-power_supply registration ordering race that produces the use-after-free.

prevent

Requiring documented, secure development processes and tools enforces correct ordering of devm_ resource acquisition so that the power_supply object outlives its IRQ handler.

prevent

Hardware or kernel memory-protection mechanisms can detect or block writes through a dangling power_supply pointer, limiting exploitability of the freed object.

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.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly incorporate memory-safety tooling and reviews that prevent most use-after-free defects.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover use-after-free issues via scanning or analysis but do not prevent their introduction.

PR.PS-02 partial match
prevents

Routine patching removes known use-after-free instances after they have been introduced in released software.

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.

detects

Security testing in development can detect use-after-free bugs before release.

prevents

Secure SDLC mandates memory-safety practices that reduce use-after-free defects.

prevents

Application security requirements can specify memory-management rules that mitigate use-after-free.

prevents

Secure architecture principles include memory-safety design choices that limit use-after-free exposure.

prevents

Secure coding standards directly prescribe avoidance of use-after-free patterns.

prevents

Change-management processes help ensure memory-safety fixes are deployed consistently.

References