RE: [PATCH v1 iwl-net] ice: fix potential NULL pointer deref in error path of ice_set_ringparam()
From: Loktionov, Aleksandr <hidden>
Date: 2026-02-20 20:05:01
Also in:
intel-wired-lan
-----Original Message-----
From: Kohei Enju <redacted>
Sent: Friday, February 20, 2026 7:40 PM
To: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
Przemyslaw [off-list ref]; Andrew Lunn
[off-list ref]; David S. Miller [off-list ref]; Eric
Dumazet [off-list ref]; Jakub Kicinski [off-list ref]; Paolo
Abeni [off-list ref]; Loktionov, Aleksandr
[off-list ref]; Alice Michael
[off-list ref]; Greenwalt, Paul [off-list ref];
Fijalkowski, Maciej [off-list ref];
kohei.enju@gmail.com; Kohei Enju [off-list ref]
Subject: [PATCH v1 iwl-net] ice: fix potential NULL pointer deref in
error path of ice_set_ringparam()
ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without
clearing ICE_TX_RING_FLAGS_TXTIME bit.
When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent
ice_setup_tx_ring() call fails, a NULL pointer dereference could
happen in the unwinding sequence:
ice_clean_tx_ring()
-> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set)
-> ice_free_tx_tstamp_ring()
-> ice_free_tstamp_ring()
-> tstamp_ring->desc (NULL deref)
Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue.
Note that this potential issue is found by manual code review.
Compile test only since unfortunately I don't have E830 devices.
Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload
support")If it's a fix, shouldn't it go to net?
quoted hunk ↗ jump to hunk
Signed-off-by: Kohei Enju <redacted> --- drivers/net/ethernet/intel/ice/ice_ethtool.c | 1 + 1 file changed, 1 insertion(+)diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.cb/drivers/net/ethernet/intel/ice/ice_ethtool.c index 7f769a90dde1..5ed86648d0d6 100644--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c@@ -3290,6 +3290,7 @@ ice_set_ringparam(struct net_device *netdev,struct ethtool_ringparam *ring, tx_rings[i].desc = NULL; tx_rings[i].tx_buf = NULL; tx_rings[i].tstamp_ring = NULL; + clear_bit(ICE_TX_RING_FLAGS_TXTIME, tx_rings[i].flags); tx_rings[i].tx_tstamps = &pf->ptp.port.tx; err = ice_setup_tx_ring(&tx_rings[i]);
If ice_setup_tx_ring() internally reads ICE_TX_RING_FLAGS_TXTIME to decide whether to allocate the tstamp_ring, then clearing the bit first means ice_setup_tx_ring() skips TxTime setup even on success - leaving TxTime silently broken after ice_set_ringparam() completes normally. The crash is fixed on the error path, but I'm afraid a functional regression is introduced on the success path. Please correct me if I'm wrong. Thank you Alex
if (err) {
--
2.51.0