CVE-2026-43216: Linux Kernel Race Condition Vulnerability

CVE-2026-43216 Overview

CVE-2026-43216 is a Linux kernel vulnerability in the networking subsystem. The flaw resides in skb_may_tx_timestamp(), which may acquire sock::sk_callback_lock in an unsafe context. Several network drivers receive TX timestamps via dedicated hardware interrupts and complete timestamp processing from the IRQ handler. Acquiring sk_callback_lock from IRQ context can deadlock the CPU when the lock is already write-held on the same processor.

The upstream kernel maintainers resolved the issue by dropping the lock and switching to READ_ONCE() and WRITE_ONCE() accessors, relying on RCU semantics for safe pointer access during socket teardown.

Critical Impact
A local condition triggered by hardware-driven TX timestamping can produce a CPU deadlock in the Linux networking stack, leading to denial of service on affected systems.

Affected Products

Linux kernel networking subsystem (net/ core, skb_may_tx_timestamp() path)
Network drivers that complete TX timestamps from a dedicated IRQ handler
Distributions shipping affected upstream kernel versions prior to the referenced stable commits

Discovery Timeline

2026-05-06 - CVE-2026-43216 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43216

Vulnerability Analysis

The vulnerability is a locking design flaw in the kernel networking stack. skb_may_tx_timestamp() is invoked when the kernel decides whether to deliver a transmit timestamp to userspace through the socket error queue. To check the socket state, the function acquires sock::sk_callback_lock, a read-write lock that is only safe to take in process or softirq context.

A subset of network device drivers does not deliver TX timestamps from softirq. Instead, they complete the timestamp from a dedicated hardware interrupt handler. When the IRQ fires on a CPU that already holds sk_callback_lock for write, the read acquisition spins indefinitely, deadlocking the CPU.

The fix removes the lock from skb_may_tx_timestamp() entirely. The socket referenced by the sk_buff remains valid until the skb is released, and the sk_socket and file members are RCU-freed, so reading them lock-free with READ_ONCE() is safe even if the user closes the socket concurrently. Matching WRITE_ONCE() calls were added where these pointers are cleared.

Root Cause

The root cause is improper lock usage across execution contexts [Race Condition / Deadlock]. sk_callback_lock was acquired in code paths reachable from hard IRQ context, violating the lock's documented usage rules and creating a same-CPU lock inversion when a writer was already active.

Attack Vector

This is not a remote code execution issue. The deadlock requires hardware-level TX timestamp completion via IRQ on a system using affected drivers and kernel versions. Exploitation requires local conditions: a workload that exercises socket timestamping while another path holds sk_callback_lock for write on the same CPU. The result is a hung CPU and a denial-of-service condition.

Because no verified proof-of-concept code is published, the mechanism is described in prose. Refer to the upstream commits 983512f, e4c6efb, and f3e4cce for the patch series.

Detection Methods for CVE-2026-43216

Indicators of Compromise

Kernel soft lockup or hard lockup messages referencing skb_may_tx_timestamp in stack traces
lockdep warnings about sk_callback_lock being acquired in hard IRQ context
CPU stalls coinciding with workloads using SO_TIMESTAMPING on hardware that delivers TX timestamps via interrupt

Detection Strategies

Inventory running kernel versions across the fleet and compare against the patched stable trees referenced in the upstream commits.
Enable CONFIG_PROVE_LOCKING in test environments to surface invalid lock contexts before deployment.
Correlate dmesg lockup reports with running NIC drivers known to use IRQ-driven TX timestamping.

Monitoring Recommendations

Forward kernel logs to a centralized log platform and alert on soft lockup, hard LOCKUP, and INFO: task ... blocked patterns.
Track /proc/lock_stat and watchdog counters on production hosts running real-time or low-latency networking workloads.
Monitor host availability and CPU stall metrics for nodes running PTP or precision timestamping services.

How to Mitigate CVE-2026-43216

Immediate Actions Required

Identify systems running affected upstream kernel versions and prioritize those using NIC drivers with IRQ-driven TX timestamping.
Apply the distribution kernel update that includes the upstream fix once available.
Reboot patched hosts to load the corrected kernel; live patching availability depends on the distribution.

Patch Information

The fix is delivered through three upstream kernel commits: 983512f, e4c6efb, and f3e4cce. The patch removes sk_callback_lock acquisition from skb_may_tx_timestamp() and replaces it with READ_ONCE() and WRITE_ONCE() accessors that rely on RCU lifetime guarantees.

Workarounds

Disable hardware TX timestamping (SO_TIMESTAMPING with hardware flags) on affected hosts where the feature is not required.
Avoid loading network drivers that perform TX timestamp completion from hard IRQ context until the patched kernel is deployed.
Where feasible, pin sensitive timestamp-using workloads to kernels that already include the upstream fix.

bash

# Verify running kernel and inspect for the fix
uname -r
zgrep -i 'skb_may_tx_timestamp' /proc/kallsyms

# Disable hardware TX timestamping on an interface as a temporary measure
hwstamp_ctl -i eth0 -t 0 -r 0