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.

# 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