Date: Sat, 11 May 2024 19:48:41 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237921] wpi: Memory leak in function wpi_free_tx_ring of sys/dev/wpi/if_wpi.c Message-ID: <bug-237921-7501-Kt1YkoQxUc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237921-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-237921-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237921 Bjoern A. Zeeb <bz@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bz@FreeBSD.org Status|Open |In Progress --- Comment #9 from Bjoern A. Zeeb <bz@FreeBSD.org> --- (In reply to Yusuf Khan from comment #8) I cannot follow the logic. wpi_free_tx_ring() is called from device detach (ignoring the attach error path); the mbuf/ring descriptor will not be used beyond that function anym= ore at that stage so there is no need to set it to NULL anymore. That would ju= st be a NOP. If there's still a reference to a ni at that stage, then other cleanup hasn= 't worked at the beginning of wpi_detach(). There should be no more ni; in f= act that should also be no more mbuf attached on the TX ring so I would even question if that code path is ever taken. This function is basically doing the opposite of wpi_alloc_tx_ring(). wpi_reset_tx_ring() on the contrary leaves all resources in place and only cleans up any outstanding transations and resets the ring to default values= ;=20 this happens in wpi_hw_stop(). And then the resources will be re-used again after wpi_parent() goes through the bringup part again (a VAP/wlan interfac= e is brought up again). So let me ask what lead to the original assumption that there may be a memo= ry leak and a possible use-after-free. If you indeed believe that, I would love to know the code path which can trigger it. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237921-7501-Kt1YkoQxUc>