CVE-2026-43216

What it actually does

This is a Linux kernel availability flaw in the network transmit timestamping path. The vulnerable function, skb_may_tx_timestamp(), can take sock::sk_callback_lock from an IRQ interrupt context when certain network drivers complete transmit timestamps from a dedicated interrupt handler. Because that lock is not safe to acquire in IRQ context, a local user who can exercise the affected timestamping behavior may trigger a same-CPU deadlock. The practical technical result is kernel lockup, stalled networking, or a system hang requiring intervention or reboot. There is no indication that the flaw enables code execution, privilege escalation, or data disclosure.

Why it matters to the business

Successful exploitation can make an affected Linux system unavailable, interrupting applications, network services, appliances, containers, or infrastructure workloads that depend on that host. The risk is most relevant for systems exposing local user access, multi-user compute environments, container platforms where local kernel attack surface is reachable, and hosts using network drivers that complete transmit timestamps from interrupt handlers. EPSS is currently very low and there is no known KEV or ransomware association, so broad active exploitation is not indicated, but the availability impact is high where the vulnerable code path is reachable.

How an attack unfolds

An attacker first needs local execution with sufficient ability to create and manipulate sockets that request transmit timestamping. They then trigger network transmit timestamp activity on an affected kernel and network driver combination where TX timestamp completion occurs from a dedicated interrupt handler. When the interrupt handler completes the timestamp, the vulnerable kernel path may call skb_may_tx_timestamp() in IRQ context. If sock::sk_callback_lock is already write-locked on the same CPU, the kernel can deadlock because the IRQ context attempts to acquire a lock that must not be taken there. The deadlock can stall the CPU, disrupt networking, and potentially hang the system, causing denial of service.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the fix for this issue. The upstream fix removes the unsafe lock acquisition from skb_may_tx_timestamp(), uses READ_ONCE() for pointer reads, and adds matching WRITE_ONCE() operations when clearing the relevant pointers. No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting untrusted container workloads, applying least-privilege controls, and disabling or avoiding workloads that require transmit timestamping on affected network devices where operationally feasible. Because this is a kernel flaw, a reboot into the fixed kernel is generally required after patch installation.

How to confirm the fix worked

Confirm that each affected system is running a kernel build that includes the upstream fix or the distribution/vendor backport. Validate using the vendor advisory, installed package changelog, and running kernel version, not only the installed-but-not-booted package version. After patching, reboot and confirm the active kernel with uname -a or equivalent platform inventory. Review kernel package changelogs for references to skb_may_tx_timestamp(), net: Drop the lock in skb_may_tx_timestamp(), sk_callback_lock, or the relevant CVE. If mitigation was chosen instead of patching, validate that untrusted users and untrusted workloads cannot access the local kernel attack surface needed to exercise TX timestamping.

Typical attack path

1. Obtain local code execution on an affected Linux system as a low-privileged user or through a constrained local workload.
2. Create sockets and enable transmit timestamping behavior using supported socket options or APIs.
3. Generate network traffic that causes transmit timestamp completion on an affected network driver path.
4. Race or repeatedly exercise the timestamp completion path until skb_may_tx_timestamp() is invoked from IRQ context while sock::sk_callback_lock is held.
5. Trigger a kernel deadlock, CPU soft lockup, network stall, or full host hang, resulting in denial of service.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, crash dumps, watchdog reports, and availability monitoring for unexplained hangs or lockups on affected kernel versions. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore analysis, hypervisor reset events, IPMI/iDRAC/iLO watchdog records, and monitoring alerts for sudden host unresponsiveness. Look for soft lockup, hard lockup, RCU stall, hung task, or deadlock messages occurring around network transmit timestamp activity. Kernel stack traces mentioning skb_may_tx_timestamp(), sock::sk_callback_lock, transmit timestamp callbacks, or NIC driver interrupt handlers are particularly relevant. Because this flaw causes denial of service rather than persistent compromise, there may be no durable file, process, account, or network IOC after reboot; detection is primarily behavioral and log-based. Correlate lockup timing with local user sessions, container activity, recent workload launches, and bursts of network timestamping or packet-generation activity.

• skb_may_tx_timestamp
• sk_callback_lock
• net: Drop the lock in skb_may_tx_timestamp
• BUG: soft lockup
• BUG: hard lockup
• NMI watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched self-detected stall
• INFO: task hung
• blocked for more than 120 seconds
• kernel: watchdog: BUG: soft lockup
• kernel: watchdog: BUG: hard lockup
• kernel: INFO: rcu_preempt detected stalls
• kernel: hung_task
• tx timestamp
• TX timestamp
• SCM_TIMESTAMPING
• SO_TIMESTAMPING

What your security team should do

• Prioritize patching Linux systems that allow local user access, run untrusted workloads, host containers, or support multi-tenant compute use cases.
• Inventory affected kernel versions across servers, appliances, virtual machine images, and container hosts; ensure the running kernel, not just the installed kernel package, is fixed.
• Review distribution and vendor advisories for exact fixed kernel package versions and required reboot procedures.
• Monitor for kernel soft lockups, hung tasks, watchdog events, unexplained host freezes, and stack traces involving skb_may_tx_timestamp() or transmit timestamp completion paths.
• Restrict untrusted local access and container privileges until systems are patched, especially on hosts with network timestamping workloads or specialized NIC drivers.
• Treat repeated unexplained kernel lockups on affected versions as potentially suspicious even though public exploit maturity and EPSS are currently low.