Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] net: ice: TOCTOU race in ice_vsi_free() leads to UAF and double-free --
commit e281bf0eed51082082d6b00b9ef0752bccc1ae10 Author: Ayush Yaduvanshi <[email protected]> net: intel: ice: Modernize ice_vsi_free() with scope-based guard(mutex) This commit updates ice_vsi_free() to use a scope-based guard for pf->sw_mutex instead of explicit mutex_lock() and mutex_unlock() calls. > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c > b/drivers/net/ethernet/intel/ice/ice_lib.c > index 9e08db376d3d0..c695df4428223 100644 > --- a/drivers/net/ethernet/intel/ice/ice_lib.c > +++ b/drivers/net/ethernet/intel/ice/ice_lib.c > @@ -457,7 +457,7 @@ void ice_vsi_free(struct ice_vsi *vsi) > return; > } > > - mutex_lock(&pf->sw_mutex); > + guard(mutex)(&pf->sw_mutex); [Severity: High] Can this sequence lead to a use-after-free and double-free? The validity check just before this lock is performed outside the mutex: if (!pf->vsi[vsi->idx] || pf->vsi[vsi->idx] != vsi) { ... return; } Does this create a race condition where two threads can bypass the check concurrently, serialize on pf->sw_mutex, and cause the second thread to dereference and double-free the VSI after the first thread clears it? > /* updates the PF for this cleared VSI */ > > pf->vsi[vsi->idx] = NULL; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
