Re: [PATCH net] ice: dpll: fix memory leak in ice_dpll_init_info error paths
From: Simon Horman <horms@kernel.org>
Date: 2026-05-28 17:14:10
Also in:
intel-wired-lan, lkml
From: 'Simon Horman' <horms@kernel.org> This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- ice: dpll: fix memory leak in ice_dpll_init_info error paths This commit fixes memory leaks in several error return paths of ice_dpll_init_info() by routing them to the deinit_info label. This ensures previously allocated resources are correctly freed.
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c --- a/drivers/net/ethernet/intel/ice/ice_dpll.c +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -4341,12 +4341,16 @@ static int ice_dpll_init_info(struct ice_pf *pf, bool cgu) alloc_size = sizeof(*de->input_prio) * d->num_inputs; de->input_prio = kzalloc(alloc_size, GFP_KERNEL); - if (!de->input_prio) - return -ENOMEM; + if (!de->input_prio) { + ret = -ENOMEM; + goto deinit_info; + }
Simon says: Although this is a pre-existing issue I believe it needs
to be assessed in the context of this patch.
If it is valid then I would suggest a separate patch,
preceding this one in a patch-set, to address it.
[Severity: Critical]
This is a pre-existing issue, but does jumping to deinit_info here expose a
double-free risk during driver resets?
When a driver reset occurs, ice_dpll_deinit_info() frees the pointers in
pf->dplls (like d->inputs, d->outputs, de->input_prio, and dp->input_prio)
but does not set them to NULL.
During the subsequent reset recovery, ice_dpll_init_info() is called. If
allocation fails here at de->input_prio, the code jumps to deinit_info
and calls ice_dpll_deinit_info() again.
Because d->outputs and dp->input_prio have not yet been overwritten with
new allocations during this init sequence, they still hold the old dangling
pointers from before the reset. Will calling ice_dpll_deinit_info() again
attempt to kfree() these old pointers, resulting in a double-free?
[ ... ]