Skip to main content
CVE-2026-43216VulnerabilityPublished Updated

skb_may_tx_timestamp() · net: Drop the lock

Affects MicrosoftSource GCVE Database

0

Not known to be exploited.

Data as of 26 Oct 2026, 17:16 UTC

Severity
Medium

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS
0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 7 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Microsoft Security Response Center MicrosoftAffected
  • =3.0
  • Microsoft
  • Azure Linux
  • 3.0
  • Azure Linux 3.0
  • kernel
Fixed in–

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.

References

Community reviews

Loading reviews…