KernelScan.io

HIGH Introduced in 4.20

tls Sockmap Race

CVE-2026-93824

CVSS 7.8 / 10.0 KernelScan AI

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

01

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.

02

Engine v0.6.0

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.

Affectednet/tls/tls_main.c (TLS)

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.

03

BranchIntroducedFixed inPatch commit
6.14.206.1.189c4896592744f
6.124.206.12.111c3d4d537337f
6.184.206.18.53a08e780b6cc1
6.64.206.6.158e26aa709454d
mainline4.207.2460e6486617c
cip/6.14.206.1.189-cip61c4896592744f
cip/6.1-rt4.206.1.189-cip61-rt32c4896592744f
cip/6.124.206.12.111-cip32c3d4d537337f

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.111-cip32
cip/6.1Fixed in 6.1.189-cip61
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Affected — no CIP fix yet (latest 5.10.271-cip78)
cip/5.10-rtAffected — no CIP fix yet (latest 5.10.268-cip77-rt34)