In the Linux kernel, the following vulnerability has been resolved:
libfs: fix get_stashed_dentry()
get_stashed_dentry() tries to optimistically retrieve a stashed dentry
from a provided location. It needs to ensure to hold rcu lock before it
dereference the stashed location to prevent UAF issues. Use
rcu_dereference() instead of READ_ONCE() it's effectively equivalent
with some lockdep bells and whistles and it communicates clearly that
this expects rcu protection.
Security readout for executives and security teams
Plain-English summary
A Linux kernel file-system helper can access a cached directory entry without the required read-copy-update protection, creating a use-after-free risk. A local, low-privileged user may be able to cause serious confidentiality, integrity, or availability impact. The supplied score is 7.8, high severity.
Executive priority
Prioritize internet-facing multi-user hosts, shared compute, and systems running untrusted workloads. This is not described as remotely exploitable, but its low-privilege local requirements and potentially complete security impact justify prompt patching during the next expedited maintenance cycle.
Technical view
get_stashed_dentry() dereferences a stashed dentry without first holding the required RCU read lock. A concurrent lifecycle change can therefore expose freed memory. The kernel fix replaces READ_ONCE() with rcu_dereference(), clarifying and enforcing the expected RCU protection and enabling lock-dependency checking.
Likely exposure
Exposure is limited to Linux systems running affected kernel builds where an unprivileged local user can reach the vulnerable libfs behavior. The bundle lists affected releases around 6.9 through 6.11, but its flattened version representation is ambiguous; confirm exact distribution package status through vendor guidance.
Exploitation context
The CVSS vector indicates local access, low complexity, low privileges, and no user interaction, with potentially high confidentiality, integrity, and availability impact. The bundle states KEV is false and provides no evidence of active exploitation or a publicly available exploit.
Researcher notes
The key defect is missing RCU-safe dereferencing around a stashed dentry, producing a race-dependent use-after-free condition. The supplied data names no CWE and does not establish practical exploitability. Exact vulnerable and fixed release boundaries should be resolved from the referenced commits and distribution advisories.
Mitigation direction
Install a vendor-supported kernel containing the fix referenced by the supplied stable-kernel commits.
Reboot into the updated kernel; installing a package alone does not replace the running kernel.
If updates are unavailable, consult the Linux distribution vendor for supported mitigations and affected-build guidance.
Restrict unnecessary local accounts and workloads until affected systems are updated.
Validation and detection
Record each system's running kernel version, distribution, architecture, and package build.
Compare package builds with the distribution's CVE advisory or fixed-kernel guidance.
Confirm the installed kernel contains the applicable referenced stable-kernel fix.
After rebooting, verify the running kernel is the remediated build.
Review local-access controls and investigate unexplained kernel crashes around affected file-system activity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-46801 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.