CVE-2026-98562: net: libwx: fix races in Tx timestamp handling
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: fix races in Tx timestamp handling
wx->ptptxskb is shared between the Tx path, the PTP auxiliary worker and the timestamp cleanup paths. The WXSTATEPTPTXINPROGRESS bit prevents multiple Tx paths from submitting timestamp requests, but does not serialize the worker against cleanup.
As a result, wxptpcleartxtimestamp() can free an skb after wxptptxhwtstampwork() has obtained its pointer. The worker may then pass the freed skb to skbtstamptx() and release the same reference again.
The cleanup path may also clear the in-progress bit while the worker is still processing the old skb. This allows the Tx path to publish a new skb which the worker can subsequently overwrite with NULL, leaking its reference.
Add a dedicated spinlock to protect publication and consumption of the Tx timestamp skb. Detach the skb and clear the in-progress bit while holding the lock, then deliver the timestamp and release the skb after dropping it. Use the same locked cleanup in the quiesce path, but keep the detach there free of register accesses: quiesce runs during PCIe error recovery, where MMIO is not reliable, and it deliberately did not touch the device before. The lock is taken with interrupts disabled, because netpoll can call ndostartxmit() with hard interrupts already off.
When handling a Tx DMA mapping failure, keep the transmit path reference until after comparing the skb under the lock. This prevents skb address reuse from making the error path mistake a newer timestamp request for the failed one.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The affected code must be handling transmit hardware timestamps through libwx. The race involves concurrent activity between the transmit path, the PTP auxiliary worker, and timestamp cleanup or quiesce paths.
What is the impact of the race?
The cleanup path can free an skb while the PTP worker still holds its pointer, allowing the worker to use that freed skb and release the reference again. A separate race can cause a newly published skb reference to be overwritten with NULL, leaking that reference.
Is PCIe error recovery relevant to this issue?
Yes. The quiesce path can run during PCIe error recovery, when MMIO access is not reliable, and it participates in timestamp cleanup. The fix uses the same locked cleanup approach while ensuring the quiesce-path detach does not access registers.
What does the fix change?
The fix adds a dedicated spinlock for publication and consumption of the transmit timestamp skb. It detaches the skb and clears the in-progress state under that lock, then delivers the timestamp and releases the skb only after dropping the lock.