PT-2026-51902 · Linux · Linux
Published
2026-06-24
·
Updated
2026-06-24
·
CVE-2026-53008
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
ice: fix race condition in TX timestamp ring cleanup
Fix a race condition between ice free tx tstamp ring() and ice tx map()
that can cause a NULL pointer dereference.
ice free tx tstamp ring currently clears the ICE TX FLAGS TXTIME flag
after NULLing the tstamp ring. This could allow a concurrent ice tx map
call on another CPU to dereference the tstamp ring, which could lead to
a NULL pointer dereference.
| CPU A:ice free tx tstamp ring() | CPU B:ice tx map() |
|---|---|
| tx ring->tstamp ring = NULL |
| ice is txtime cfg() -> true
| tstamp ring = tx ring->tstamp ring
| tstamp ring->count // NULL deref!flags &= ~ICE TX FLAGS TXTIME |
Fix by:
- Reordering ice free tx tstamp ring() to clear the flag before NULLing the pointer, with smp wmb() to ensure proper ordering.
- Adding smp rmb() in ice tx map() after the flag check to order the flag read before the pointer read, using READ ONCE() for the pointer, and adding a NULL check as a safety net.
- Converting tx ring->flags from u8 to DECLARE BITMAP() and using atomic bitops (set bit(), clear bit(), test bit()) for all flag operations throughout the driver:
- ICE TX RING FLAGS XDP
- ICE TX RING FLAGS VLAN L2TAG1
- ICE TX RING FLAGS VLAN L2TAG2
- ICE TX RING FLAGS TXTIME
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux