> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of Jacob > Keller > Sent: 07 August 2025 23:05 > To: Kitszel, Przemyslaw <[email protected]>; Intel Wired LAN > <[email protected]>; [email protected] > Cc: Keller, Jacob E <[email protected]> > Subject: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: fix NULL access of > tx->in_use in ice_ptp_ts_irq > > The E810 device has support for a "low latency" firmware interface to access > and read the Tx timestamps. This interface does not use the standard Tx > timestamp logic, due to the latency overhead of proxying sideband command > requests over the firmware AdminQ. > > The logic still makes use of the Tx timestamp tracking structure, ice_ptp_tx, > as it uses the same "ready" bitmap to track which Tx timestamps. > > Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker is > initialized before its first access. This results in NULL dereference or > use-after-free bugs similar to the following: > > [245977.278756] BUG: kernel NULL pointer dereference, address: > 0000000000000000 [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40 > [245977.278796] Call Trace: [245977.278809] ? ice_misc_intr+0x364/0x380 [ice] > > This can occur if a Tx timestamp interrupt races with the driver reset logic. > > Fix this by only checking the in_use bitmap (and other fields) if the tracker > is marked as initialized. The reset flow will clear the init field under lock > before it tears the tracker down, thus preventing any use-after-free or NULL > access. > > Fixes: f9472aaabd1f ("ice: Process TSYN IRQ in a separate function") > Signed-off-by: Jacob Keller <[email protected]> > --- > drivers/net/ethernet/intel/ice/ice_ptp.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) >
Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
