[PATCH iwl-net] ice: only free LL TS IRQ when the handler is present

[PATCH iwl-net] ice: only free LL TS IRQ when the handler is present

[Aleksandr Loktionov]

From: Sergey Temerkhanov <sergey.temerkhanov@intel.com>

Free LL TS IRQ handler only when the handler was previously installed.
Unguarded calls to ice_free_irq_msix_ll_ts() may result in a double
free when the LL TS interrupt is not supported by the firmware because
ll_ts_irq.index is zero-initialised and would pass the index >= 0 check.

Track whether the LL TS IRQ was successfully requested by initialising
ll_ts_irq.index to -ENOENT in ice_init_pf() and when taking the
"not supported" skip path or on request failure, then guard the free
paths with ll_ts_irq.index >= 0.

Fixes: 82e71b226e0e ("ice: Enable SW interrupt from FW for LL TS")
Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 3c36e36..cc3743a 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3389,7 +3389,7 @@ static void ice_free_irq_msix_misc(struct ice_pf *pf)
 	devm_free_irq(ice_pf_to_dev(pf), misc_irq_num, pf);
 
 	ice_free_irq(pf, pf->oicr_irq);
-	if (pf->hw.dev_caps.ts_dev_info.ts_ll_int_read)
+	if (pf->ll_ts_irq.index >= 0)
 		ice_free_irq_msix_ll_ts(pf);
 }
 
@@ -3473,8 +3473,10 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
 	}
 
 	/* reserve one vector in irq_tracker for ll_ts interrupt */
-	if (!pf->hw.dev_caps.ts_dev_info.ts_ll_int_read)
+	if (!pf->hw.dev_caps.ts_dev_info.ts_ll_int_read) {
+		pf->ll_ts_irq.index = -ENOENT;
 		goto skip_req_irq;
+	}
 
 	irq = ice_alloc_irq(pf, false);
 	if (irq.index < 0)
@@ -3487,6 +3489,7 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
 		dev_err(dev, "devm_request_irq for %s failed: %d\n",
 			pf->int_name_ll_ts, err);
 		ice_free_irq(pf, pf->ll_ts_irq);
+		pf->ll_ts_irq.index = -ENOENT;
 		return err;
 	}
 
@@ -3496,7 +3499,7 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
 	ice_ena_ctrlq_interrupts(hw, pf->oicr_irq.index);
 	/* This enables LL TS interrupt */
 	pf_intr_start_offset = rd32(hw, PFINT_ALLOC) & PFINT_ALLOC_FIRST;
-	if (pf->hw.dev_caps.ts_dev_info.ts_ll_int_read)
+	if (pf->ll_ts_irq.index >= 0)
 		wr32(hw, PFINT_SB_CTL,
 		     ((pf->ll_ts_irq.index + pf_intr_start_offset) &
 		      PFINT_SB_CTL_MSIX_INDX_M) | PFINT_SB_CTL_CAUSE_ENA_M);
@@ -4090,6 +4093,7 @@ int ice_init_pf(struct ice_pf *pf)
 	 * the misc functionality and queue processing is combined in
 	 * the same vector and that gets setup at open.
 	 */
+	pf->ll_ts_irq.index = -ENOENT;
 	err = ice_req_irq_msix_misc(pf);
 	if (err) {
 		dev_err(dev, "setup of misc vector failed: %d\n", err);
-- 
2.52.0

Re: [PATCH iwl-net] ice: only free LL TS IRQ when the handler is present

[Simon Horman]

On Fri, Apr 24, 2026 at 08:19:58AM +0200, Aleksandr Loktionov wrote:
> From: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
> 
> Free LL TS IRQ handler only when the handler was previously installed.
> Unguarded calls to ice_free_irq_msix_ll_ts() may result in a double
> free when the LL TS interrupt is not supported by the firmware because
> ll_ts_irq.index is zero-initialised and would pass the index >= 0 check.
> 
> Track whether the LL TS IRQ was successfully requested by initialising
> ll_ts_irq.index to -ENOENT in ice_init_pf() and when taking the
> "not supported" skip path or on request failure, then guard the free
> paths with ll_ts_irq.index >= 0.
> 
> Fixes: 82e71b226e0e ("ice: Enable SW interrupt from FW for LL TS")
> Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>

FTR: There is an AI generated review of this patch available on sashiko.dev.
I believe the issues flagged there pre-date this patch and do not impact
this patch. So while I do not think they should block progress of this
patch I suggest looking over them to see if any follow-up is warranted.