In the Linux kernel, the following vulnerability has been resolved:
ice: fix race condition in TX timestamp ring cleanup
Fix a race condition between icefreetxtstampring() and icetxmap() that can cause a NULL pointer dereference.
icefreetxtstampring currently clears the ICETXFLAGSTXTIME flag after NULLing the tstampring. This could allow a concurrent icetxmap call on another CPU to dereference the tstampring, which could lead to a NULL pointer dereference.
CPU A:icefreetxtstampring() | CPU B:icetxmap() --------------------------------|--------------------------------- txring->tstampring = NULL | | iceistxtimecfg() -> true | tstampring = txring->tstampring | tstampring->count // NULL deref! flags &= ~ICETXFLAGSTXTIME |
Fix by: 1. Reordering icefreetxtstampring() to clear the flag before NULLing the pointer, with smpwmb() to ensure proper ordering. 2. Adding smprmb() in icetxmap() after the flag check to order the flag read before the pointer read, using READONCE() for the pointer, and adding a NULL check as a safety net. 3. Converting txring->flags from u8 to DECLAREBITMAP() and using atomic bitops (setbit(), clearbit(), testbit()) for all flag operations throughout the driver: - ICETXRINGFLAGSXDP - ICETXRINGFLAGSVLANL2TAG1 - ICETXRINGFLAGSVLANL2TAG2 - ICETXRINGFLAGSTXTIME
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix PTP NULL pointer dereference during VSI rebuild
Fix race condition where PTP periodic work runs while VSI is being rebuilt, accessing NULL vsi->rxrings.
The sequence was: 1. iceptpprepareforreset() cancels PTP work 2. iceptprebuild() immediately queues PTP work 3. VSI rebuild happens AFTER iceptprebuild() 4. PTP work runs and accesses NULL vsi->rxrings
Fix: Keep PTP work cancelled during rebuild, only queue it after VSI rebuild completes in icerebuild().
Added iceptpqueuework() helper function to encapsulate the logic for queuing PTP work, ensuring it's only queued when PTP is supported and the state is ICEPTPREADY.
Error log: [ 121.392544] ice 0000:60:00.1: PTP reset successful [ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 121.392712] #PF: supervisor read access in kernel mode [ 121.392720] #PF: errorcode(0x0000) - not-present page [ 121.392727] PGD 0 [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary) [ 121.392761] Tainted: [S]=CPUOUTOFSPEC [ 121.392773] RIP: 0010:iceptpupdatecachedphctime+0xbf/0x150 [ice] [ 121.393042] Call Trace: [ 121.393047] <TASK> [ 121.393055] iceptpperiodicwork+0x69/0x180 [ice] [ 121.393202] kthreadworkerfn+0xa2/0x260 [ 121.393216] ? pfxiceptpperiodicwork+0x10/0x10 [ice] [ 121.393359] ? pfxkthreadworkerfn+0x10/0x10 [ 121.393371] kthread+0x10d/0x230 [ 121.393382] ? pfxkthread+0x10/0x10 [ 121.393393] retfromfork+0x273/0x2b0 [ 121.393407] ? pfxkthread+0x10/0x10 [ 121.393417] retfromforkasm+0x1a/0x30 [ 121.393432] </TASK>
In the Linux kernel, the following vulnerability has been resolved:
ice: ptp: don't WARN when controlling PF is unavailable
In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrlpf) is never initialized in the VM, so icegetctrlptp() returns NULL and triggers WARNON() in iceptpsetuppf().
Since this is an expected behavior in that configuration, replace WARNON() with an informational message and return -EOPNOTSUPP.