> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of > ZhaoJinming > Sent: 29 May 2026 11:08 > To: Nguyen, Anthony L <[email protected]>; Kitszel, Przemyslaw > <[email protected]>; Andrew Lunn <[email protected]>; David S > . Miller <[email protected]>; Eric Dumazet <[email protected]>; Jakub > Kicinski <[email protected]>; Paolo Abeni <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; ZhaoJinming <[email protected]> > Subject: [Intel-wired-lan] [PATCH net v2 1/2] ice: dpll: set pointers to NULL > after kfree in ice_dpll_deinit_info > > ice_dpll_deinit_info() calls kfree() on several pf->dplls fields (inputs, > outputs, eec.input_prio, pps.input_prio) but does not set the pointers to > NULL afterward. This leaves dangling pointers in the > pf->dplls structure. > > While not currently exploitable through existing code paths, this is unsafe > because: > > 1. If ice_dpll_init_info() is called again after a deinit (e.g. during > driver recovery), and a subsequent allocation within init fails, the > error path will jump to deinit_info and call ice_dpll_deinit_info() > again. Since some pointers still hold the old freed addresses, this > would result in a double-free. > > 2. Any future code that checks these pointers before use or after free > would be unprotected against use-after-free. > > Follow the common kernel convention of setting pointers to NULL after > kfree() so that: > - kfree(NULL) is a safe no-op, preventing double-free > - NULL checks on these pointers become meaningful > > This is a preparatory fix for a subsequent patch that routes additional error > paths in ice_dpll_init_info() to the deinit_info label. > > Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") > Signed-off-by: ZhaoJinming <[email protected]> > --- > drivers/net/ethernet/intel/ice/ice_dpll.c | 4 ++++ > 1 file changed, 4 insertions(+) >
Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
