CVE-2026-93824 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
tls: reject the combination of TLS and sockmap
TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable.
We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock).
This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel has addressed a significant security concern regarding the integration between Transport Layer Security (TLS) and sockmap functionality within BPF programs. This vulnerability stems from latent bugs inherent in combining these two features, which present exploitable conditions that could potentially be leveraged by attackers to compromise system integrity or availability. Although no active users were identified utilizing this specific configuration at the time of discovery, the potential for exploitation remains a critical risk due to the complexity and depth of interactions between TLS protocols and socket mapping mechanisms in kernel space.
The core technical flaw lies in the inability to safely manage concurrent access when configuring TLS keys on sockets that are part of a sockmap. Previous attempts to mitigate this issue involved rejecting the addition of TLS as an upper layer protocol through checks within sk_psock_init, specifically using inet_csk_has_ulp. However, this approach proved insufficient because it did not prevent race conditions during key configuration. Since sockmap operations do not hold the socket lock consistently, there exists a window where parallel execution can lead to inconsistent states or memory corruption vulnerabilities that are difficult to detect but easy to exploit in practice.
To resolve these issues, the kernel developers implemented a minimal rejection mechanism for this feature combination. This patch explicitly blocks attempts to configure TLS keys on sockets associated with sockmaps, thereby eliminating the attack surface created by race conditions during key setup. The decision was made to reject rather than attempt immediate full cleanup because a comprehensive fix would require a major rewrite of the transmission path and removal of skmsg dependencies, which is beyond the scope of an urgent security patch. Instead, this change serves as a defensive measure while subsequent patches handle dead code removal and further architectural refinements.
From a vulnerability classification perspective, this issue aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as race conditions. The lack of proper locking mechanisms during critical configuration steps allows for state inconsistencies that can lead to undefined behavior or privilege escalation scenarios if exploited correctly. In terms of the MITRE ATT&CK framework, this vulnerability could potentially facilitate lateral movement or persistence within a compromised environment by exploiting kernel-level flaws to bypass security controls or escalate privileges from user space to ring zero.
The operational impact of leaving this integration enabled includes potential system crashes, data leakage through memory corruption, and unauthorized access to sensitive communications handled via TLS. By rejecting the combination entirely, the Linux kernel ensures that administrators cannot inadvertently expose their systems to these risks while more robust architectural solutions are developed in future releases. This approach prioritizes stability and security over feature completeness for a niche use case with no known active deployments.
Mitigation strategies primarily involve ensuring that system configurations do not attempt to combine TLS sockets with sockmap functionality. For environments where such integration might be desired, administrators should monitor kernel updates closely and apply this patch as soon as it is available in their distribution repositories. Additionally, security teams should audit BPF program implementations to ensure they adhere to best practices regarding socket locking and resource management, reducing the likelihood of similar race conditions arising from other custom or third-party extensions.