HIGH Introduced in 4.20
tls Sockmap Race
CVE-2026-93824
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
01Description
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.
02KernelScan AI Analysis
Risk summary
A local attacker who can obtain BPF capabilities—typically through a user namespace on systems where unprivileged BPF or userns is enabled—can trigger exploitable memory corruption by configuring TLS keys on a socket already attached to a BPF sockmap. The combination of TLS and sockmap on the same socket exposes latent bugs in the transmit path that the kernel maintainers describe as definitely exploitable, potentially leading to kernel code execution and container escape.
Vulnerability analysis
The TLS and BPF sockmap (psock) subsystems can both attach to the same socket, and their combined interaction in the transmit path contains latent memory corruption bugs that are exploitable. The race exists because sockmap does not hold the socket lock, so there is a window where a socket can be in a sockmap and then have TLS keys configured on it, or vice versa, without either subsystem being aware of the other. The fix makes TLS and sockmap mutually exclusive by rejecting TLS key configuration on any socket that already has a psock attached; sockmap already rejected TLS sockets, so both directions of the unsafe combination are now blocked. A local user who can obtain BPF capabilities—achievable through user namespaces on many systems—can create a socket, add it to a sockmap, then attempt TLS configuration, triggering the exploitable corruption. No network packets or specific hardware are required; the attack is launched entirely through local socket operations and BPF map updates.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.1 | 4.20 | 6.1.189 | c4896592744f |
| 6.12 | 4.20 | 6.12.111 | c3d4d537337f |
| 6.18 | 4.20 | 6.18.53 | a08e780b6cc1 |
| 6.6 | 4.20 | 6.6.158 | e26aa709454d |
| mainline | 4.20 | 7.2 | 460e6486617c |
| cip/6.1 | 4.20 | 6.1.189-cip61 | c4896592744f |
| cip/6.1-rt | 4.20 | 6.1.189-cip61-rt32 | c4896592744f |
| cip/6.12 | 4.20 | 6.12.111-cip32 | c3d4d537337f |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Affected — no CIP fix yet (latest 5.10.271-cip78) |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |