In update_eth_regs_async() neither the URB nor the request structure are being freed if usb_submit_urb() fails. The patch fixes this long lurking bug in the error path.
Signed-off-by: Petko Manolov petko.manolov@konsulko.com --- drivers/net/usb/pegasus.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c index 81ca64debc5b..7a70207e7364 100644 --- a/drivers/net/usb/pegasus.c +++ b/drivers/net/usb/pegasus.c @@ -168,6 +168,8 @@ static int update_eth_regs_async(pegasus_t *pegasus) netif_device_detach(pegasus->net); netif_err(pegasus, drv, pegasus->net, "%s returned %d\n", __func__, ret); + kfree(req); + usb_free_urb(async_urb); } return ret; }
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opti...
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH] net: usb: pegasus: fix memory leak on usb_submit_urb() failure Link: https://lore.kernel.org/stable/20251216184113.197439-1-petko.manolov%40konsu...
On 12/16/25 7:41 PM, Petko Manolov wrote:
In update_eth_regs_async() neither the URB nor the request structure are being freed if usb_submit_urb() fails. The patch fixes this long lurking bug in the error path.
Signed-off-by: Petko Manolov petko.manolov@konsulko.com
Please: - include the targed tree in the subj prefix ('net' in this case) - include a suitable Fixes tag
Thanks,
Paolo
On 25-12-23 12:44:53, Paolo Abeni wrote:
On 12/16/25 7:41 PM, Petko Manolov wrote:
In update_eth_regs_async() neither the URB nor the request structure are being freed if usb_submit_urb() fails. The patch fixes this long lurking bug in the error path.
Signed-off-by: Petko Manolov petko.manolov@konsulko.com
Please:
- include the targed tree in the subj prefix ('net' in this case)
- include a suitable Fixes tag
Sure, will do. However, my v2 patch makes use of __free() cleanup functionality, which in turn only applies back to v6.6 stable kernels.
I guess i shall make another version of the patch that is suitable only for v5.4 to v6.1 stable releases, right? How shall i format the patch so that it targets only these old versions?
cheers, Petko
Sure, will do. However, my v2 patch makes use of __free() cleanup functionality, which in turn only applies back to v6.6 stable kernels.
I would suggest not using the magical __free() cleanup.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#using-...
Low level cleanup constructs (such as __free()) can be used when building APIs and helpers, especially scoped iterators. However, direct use of __free() within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function.
Andrew
On 26-01-02 23:02:53, Andrew Lunn wrote:
Sure, will do. However, my v2 patch makes use of __free() cleanup functionality, which in turn only applies back to v6.6 stable kernels.
I would suggest not using the magical __free() cleanup.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#using-...
Low level cleanup constructs (such as __free()) can be used when building APIs and helpers, especially scoped iterators. However, direct use of __free() within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function.
Heh, __free() is OK for APIs, but not drivers...
Maybe this text is a relic from the times auto cleanup was not fully understood?
Petko
linux-stable-mirror@lists.linaro.org
-
Andrew Lunn -
kernel test robot -
Paolo Abeni -
Petko Manolov