CVE-2024-50273
Linux Kernel 4.10 – 4.19.324
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2024-50273 is a high-severity Use of Uninitialized Resource (CWE-908) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique OS Credential Dumping (T1003); ranked at the 21th 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-2024-44775
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref…
more
from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.
- 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 (including static analysis) can find uses of uninitialized resources after they are coded.
Requiring documented development standards and tools can mandate initialization checks and safe patterns that stop the weakness from being introduced.
Engineering principles can require explicit resource initialization before use, structurally avoiding uninitialized access.
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 activities such as static analysis and code review directly prevent use of uninitialized resources while also addressing many other weaknesses.
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 and acceptance can detect uninitialized resource usage through dynamic analysis and fuzzing.
Secure development life cycle mandates initialization checks and static analysis that can catch uninitialized resource use.
Application security requirements can specify mandatory initialization of variables and resources before use.
Secure system architecture and engineering principles include defensive coding practices that prevent use of uninitialized memory or objects.
Secure coding standards directly require explicit initialization of all variables and resources, substantially mitigating CWE-908.