CVE-2024-50186: net: explicitly clear the sk pointer, when pf->create fails
In the Linux kernel, the following vulnerability has been resolved:
net: explicitly clear the sk pointer, when pf->create fails
We have recently noticed the exact same KASAN splat as in commit
6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
creation fails"). The problem is that commit did not fully address the
problem, as some pf->create implementations do not use sk_common_release
in their error paths.
For example, we can use the same reproducer as in the above commit, but
changing ping to arping. arping uses AF_PACKET socket and if packet_create
fails, it will just sk_free the allocated sk object.
While we could chase all the pf->create implementations and make sure they
NULL the freed sk object on error from the socket, we can't guarantee
future protocols will not make the same mistake.
So it is easier to just explicitly NULL the sk pointer upon return from
pf->create in __sock_create. We do know that pf->create always releases the
allocated sk object on error, so if the pointer is not NULL, it is
definitely dangling.
Security readout for executives and security teams
Plain-English summary
A failed Linux network-socket creation can leave the kernel holding a pointer to memory it already freed. This use-after-free could let a low-privileged local user cause serious confidentiality, integrity, or availability impact. The supplied assessment rates it 7.8 High, but does not establish practical code execution or active attacks.
Executive priority
Prioritize prompt remediation on systems permitting low-privileged local access. Internet-only exposure is not indicated, but the potential impact is high. Track vendor kernel deployment and required reboots through completion.
Technical view
When certain protocol-family create handlers, including packet_create, fail, they free the allocated socket object without clearing its sk pointer. Later handling can therefore encounter a dangling pointer. The correction centrally clears sk in __sock_create after pf->create returns an error, avoiding reliance on every protocol implementation to perform that cleanup.
Likely exposure
Potential exposure is limited to Linux systems running an affected kernel and reachable by a low-privileged local user. The supplied version data mixes releases and commit identifiers, so organizations should map distribution kernels and backports to the referenced stable corrections rather than relying only on version-string comparisons.
Exploitation context
The CVSS vector indicates local access, low privileges, low complexity, and no user interaction. The bundle does not identify this CVE as KEV-listed or cite active exploitation. Its arping/AF_PACKET example demonstrates the underlying failure during testing, not confirmed malicious exploitation.
Researcher notes
This is CWE-416. The earlier 6cd4a78d962b change was incomplete because not every pf->create error path uses sk_common_release. The centralized __sock_create correction addresses current and future protocol handlers. The supplied sources establish the bug and fixes, but not reliable exploitation, exploitability across every configuration, or observed attacks.
Mitigation direction
Apply the vendor-supported kernel update containing the applicable referenced stable correction.
Reboot into the updated kernel after installation so the corrected code is active.
Consult distribution security guidance to resolve backported kernel versions accurately.
Until updated, reduce unnecessary low-privileged local access where operationally feasible.
Validation and detection
Inventory running kernel versions, including vendor package release and architecture.
Map each vendor kernel package to CVE-2024-50186 advisories or referenced stable commits.
After rebooting, confirm systems are running the intended updated kernel package.
Review kernel diagnostics for relevant use-after-free or KASAN reports; absence alone does not prove safety.
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.
cwe · low confidence lookup
CWE-416: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
2CVSS vectors
3Timeline events
2ADP providers
7Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-416 · source CWE mapping
Use After Free
Use After Free represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.