netdev - Re: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: fix NULL access of tx->in_use in ice_ptp_ts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <afb633cc-b399-4610-9fde-ee4e1984f790@intel.com>
Date: Thu, 7 Aug 2025 16:56:29 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: fix NULL access of
 tx->in_use in ice_ptp_ts_irq



On 8/7/2025 2:29 PM, Paul Menzel wrote:
> Dear Jacob,
> 
> 
> Thank you for the patch.
> 
> Am 07.08.25 um 19:35 schrieb Jacob Keller:
>> 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.
> 
> Do you have a reproducer?
> 

Not reliably. Pretty much any time you have a Tx timestamp occurring
simultaneously with a device reset could trigger it. I believe this was
reported by a customer along side a firmware update which triggered the
EMP reset logic on one function while another function had active Tx
timestamps going. I wasn't able to reliably reproduce the issue on my
setup yet, but it is quite obvious from inspecting the reported panic
which I included here in minified form.

>> 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.
> 
> Great commit message. Thank you for taking the time to write this down.
> 

Thanks,
Jake
> 
> Reviewed-by: Paul Menzel <pmenzel@...gen.mpg.de>
> 
> 
> Kind regards,
> 
> Paul



Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)