On 10/2/2026 4:19 AM, Anurag Mandal wrote:
ice_tx_queue_start() dereferences the Tx time queue context buffer returned by ice_malloc() without NULL check. On allocation failure, the E830 send-on-timestamp path therefore crashes instead of reporting "No Memory" error, and also the already allocated txq_elem buffer gets leaked.Added the necessary allocation failure check and freed txq_elem buffer in case of failure to avoid the memory leak. Fixes: 0b6ff09a1f19 ("net/intel: support Tx packet pacing for E830") Cc: [email protected] Signed-off-by: Anurag Mandal <[email protected]> --- drivers/net/intel/ice/ice_rxtx.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/intel/ice/ice_rxtx.c b/drivers/net/intel/ice/ice_rxtx.c index b333444cbf..873aca0100 100644 --- a/drivers/net/intel/ice/ice_rxtx.c +++ b/drivers/net/intel/ice/ice_rxtx.c @@ -898,6 +898,10 @@ ice_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id) u8 ts_buf_len = ice_struct_size(ts_elem, txtimeqs, 1);ts_elem = ice_malloc(hw, ts_buf_len);+ if (!ts_elem) { + rte_free(txq_elem); + return -ENOMEM; + } ice_setup_txtime_ctx(txq, &txtime_ctx, true); ice_set_ctx(hw, (u8 *)&txtime_ctx, ts_elem->txtimeqs[0].txtime_ctx,
I don't particularly like the fact that we're allocating using `ice_malloc` but freeing using `rte_free`. This works only accidentally (because `ice_malloc` resolves to `rte_malloc`).
Not a blocker for this patch, as this is following established convention in this function, but IMO this code could benefit from a separate patch replacing direct `rte_free` calls with `ice_free`.
Acked-by: Anatoly Burakov <[email protected]> -- Thanks, Anatoly
