From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA722374A0F for ; Sat, 4 Jul 2026 17:14:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783185274; cv=none; b=knD6pdRGRSNZPqc5SsVIpE5MLGTaenDjhwiIxWmtVAmCfTaTnAnu4RaFnsModDapXko62ghRKJz0Ic22HpRVcZ6HaMdNaQI1vVT07e7yjg9jIGr4DJQ7InoYTNrL02+fqXX0vPtNXYyIqTa9CbaE1ytO0h+QnXXR9qPP3V6bmhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783185274; c=relaxed/simple; bh=utN24TCARRk/6LkTza7v33zPnWXEMWED6WBO24S/wHk=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=UKetjSO38neuHzhNCF1+GB1jsyyRT7OK9Z19s8c0XzW1+WITmel2Gt0AT6ECHtnhcZhxSa3oyJnXtYwzz41Fy7KPqAqz4xp28hQJABWWq1Byx2z2O+nXtxyV6yIXpV8tyPe4Y9L1AHS/rtOjd7m16xa+5QkdhC9yY9gKd5ffd0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QkDlTsoO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QkDlTsoO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A1881F000E9; Sat, 4 Jul 2026 17:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783185273; bh=JpY4tKnWPsgc5bQoC1BVkSyG0VWsGmnxP7TWEabudHk=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=QkDlTsoOws7KEhB+cw0QkPFDU1ZdlvhaiKjZ3EnOwI9UIptXa/hWFMU6eB9LIzjQj RnfYdtZzZdSO6VMOC/Zxra4Mj2o80xnqu0WguPhdc9GosdYLa6+WM8fDUg/1o7lUfX MaM2lg70KI1uYDR9v/ONQdoLNJAC0YJs/XRAte06gFqi3Kgtvf7+vtS7d8CaolP/ei 1nI3VnveRhWe8o0ZOiRAAhli9tsR+YVx3juIs8AmDlN3beMn4EiC5+QxUN1cKYpuVo x5Ad9W5witzDDp6zADFqocA7D8mEmupSMbfqRLHk967ExulaDggNFY9Co0/GG110hE ANEYBsNMjAYsg== From: sashiko-bot@kernel.org Subject: Re: [PATCH] can: usb: etas_es58x: Fix RX buffer leak on URB resubmit failure Reply-To: sashiko-reviews@lists.linux.dev To: "Guangshuo Li" Cc: linux-can@vger.kernel.org, "Vincent Mailhol" , "Marc Kleine-Budde" , "Oliver Hartkopp" , "Oleksij Rempel" In-Reply-To: <20260704165717.248880-1-lgs201920130244@gmail.com> References: <20260704165717.248880-1-lgs201920130244@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 04 Jul 2026 17:14:32 +0000 Message-Id: <20260704171433.3A1881F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-can@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] Race condition during device disconnect leads to a Use-After-Free = of the `netdev` structure in the URB completion handler. -- commit 60846d2bc70af068d7027f0af965d52838e69d83 Author: Guangshuo Li can: usb: etas_es58x: Fix RX buffer leak on URB resubmit failure This commit reuses the free_urb path after an RX URB resubmit failure in es58x_read_bulk_callback(). This prevents a memory leak of the coherent transfer buffer when usb_submit_urb() fails. > diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/ca= n/usb/etas_es58x/es58x_core.c > index b259f61098083..da12a35dd2f9a 100644 > --- a/drivers/net/can/usb/etas_es58x/es58x_core.c > +++ b/drivers/net/can/usb/etas_es58x/es58x_core.c > @@ -1476,7 +1476,7 @@ static void es58x_read_bulk_callback(struct urb *ur= b) > dev_err_ratelimited(dev, > "Failed resubmitting read bulk urb: %pe\n", > ERR_PTR(ret)); > - return; > + goto free_urb; [Severity: High] This is a pre-existing issue, but does a race condition exist during device disconnect that leads to a use-after-free of the netdev structure? If a dual-channel ES58x device is abruptly disconnected, es58x_disconnect() calls es58x_free_netdevs() to iteratively free the channels. When it unregisters the first channel, opened_channel_cnt drops to 1, so es58x_free_urbs() is not called yet, and URBs continue running concurrently. Meanwhile, es58x_free_netdevs() frees the first channel's netdev: drivers/net/can/usb/etas_es58x/es58x_core.c:es58x_free_netdevs() { ... es58x_dev->netdev[i] =3D NULL; free_candev(netdev); ... } If a concurrent es58x_read_bulk_callback() fails to resubmit its URB and receives -ENODEV due to the disconnect, it iterates over all channels just above this diff hunk: drivers/net/can/usb/etas_es58x/es58x_core.c:es58x_read_bulk_callback() { ... if (ret =3D=3D -ENODEV) { for (i =3D 0; i < es58x_dev->num_can_ch; i++) if (es58x_dev->netdev[i]) netif_device_detach(es58x_dev->netdev[i]); ... } Could the callback read the netdev pointer before it is set to NULL, but execute netif_device_detach() on it after free_candev() has already freed i= t? > =20 > free_urb: > usb_free_coherent(urb->dev, urb->transfer_buffer_length, --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260704165717.2488= 80-1-lgs201920130244@gmail.com?part=3D1