CVE-2026-43216: net: Drop the lock in skb_may_tx_timestamp()
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.
Security readout for executives and security teams
Plain-English summary
A Linux networking flaw can deadlock the kernel when certain network drivers complete transmit timestamps from a dedicated hardware interrupt. An affected system could become unresponsive, creating an availability risk. The supplied sources do not establish severity, practical attacker reachability, or active exploitation.
Executive priority
Treat as a targeted availability remediation rather than a confirmed emergency. Promptly inventory exposed kernel and driver combinations, then apply supported updates during the next appropriate maintenance window. Escalate priority for critical network systems using hardware transmit timestamping or experiencing unexplained hangs.
Technical view
skb_may_tx_timestamp() could acquire sk_callback_lock in IRQ context, where that lock is unsafe. If already write-locked on the same CPU, timestamp completion can deadlock. The kernel fix removes the lock, reads socket pointers with READ_ONCE(), and adds matching WRITE_ONCE() operations when clearing them.
Likely exposure
Exposure requires an affected Linux kernel and a driver that completes transmit timestamps from a dedicated interrupt. Systems using transmit hardware timestamping may warrant closer review. The supplied version data identifies affected releases but does not specify distributions, hardware models, configurations, privileges, or remote reachability.
Exploitation context
The source bundle marks this CVE as absent from KEV and provides no evidence of active exploitation, public proof-of-concept activity, or weaponization. It describes a deadlock condition, but does not establish whether an unprivileged local or remote actor can reliably trigger it.
Researcher notes
The stated fault is improper lock acquisition in hard IRQ context, producing a same-CPU deadlock when sk_callback_lock is already write-held. Socket lifetime remains protected until skb release, while socket and credential-related objects are RCU-freed. The sources do not provide CVSS, CWE, trigger prerequisites, crash traces, or exploitability analysis.
Mitigation direction
Install a vendor-supported kernel update containing the applicable referenced stable fix.
Check distribution advisories for package-specific fixed versions and required reboot guidance.
Prioritize systems using transmit hardware timestamping or relevant interrupt-driven network drivers.
If updates are unavailable, request vendor guidance for supported temporary mitigations.
Validation and detection
Record each system's running kernel version, distribution package release, and network drivers.
Map vendor package changelogs to the applicable referenced Linux stable commit.
Confirm the updated kernel is running after installation and any required reboot.
Review logs and monitoring for unexplained hangs associated with transmit timestamp activity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43216 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
9Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 6, 2026, 11:28 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.