CVE-2026-43216
Awaiting Analysis Awaiting Analysis - Queue
Linux Kernel skb_may_tx_timestamp() Deadlock Fix

Publication date: 2026-05-06

Last updated on: 2026-05-06

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-06
Last Modified
2026-05-06
Generated
2026-05-07
AI Q&A
2026-05-06
EPSS Evaluated
N/A
NVD
CVE-2026-43216
EUVD
EUVD-2026-27776
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's networking code, specifically in the function skb_may_tx_timestamp(). The function may acquire a lock called sk_callback_lock, which must not be taken in interrupt request (IRQ) context but only in softirq context.

Some drivers receive timestamps via a dedicated interrupt and complete the transmit (TX) timestamp from that interrupt handler. If the lock is already write-locked on the same CPU, acquiring it again in this context can cause a deadlock.

The fix involves dropping the lock acquisition in skb_may_tx_timestamp() and instead safely accessing the socket pointer using READ_ONCE() and WRITE_ONCE() primitives to avoid race conditions, ensuring the socket remains valid until the socket buffer (skb) is released.


How can this vulnerability impact me? :

This vulnerability can lead to a deadlock situation in the Linux kernel networking stack when certain drivers handle transmit timestamps via interrupts. A deadlock can cause the affected system or network functionality to hang or become unresponsive, potentially impacting system stability and network performance.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved by dropping the lock in skb_may_tx_timestamp() to avoid deadlocks caused by acquiring sock::sk_callback_lock in IRQ context.

To mitigate this vulnerability, you should update your Linux kernel to the fixed version where this issue is resolved.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart