From: Simon Horman <horms@kernel.org>
To: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Cc: isdn@linux-pingi.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
Date: Wed, 29 Oct 2025 16:45:06 +0000 [thread overview]
Message-ID: <aQJEkvtfmG-sEA3v@horms.kernel.org> (raw)
In-Reply-To: <f2xnihnjrvh6qqqqtqev6zx47pjhxd5kpgdahibdsgtg7ran2d@z6yerx5rddsr>
On Tue, Oct 28, 2025 at 10:08:44PM +0530, Abdun Nihaal wrote:
> On Tue, Oct 28, 2025 at 12:32:31PM +0000, Simon Horman wrote:
> > I agree that this is a bug, and that it was introduced in the cited commit.
>
> Thanks for reviewing the patch.
>
> > I think it would be good to add something to the commit message
> > regarding how the problem was found, e.g. which tool was used, or
> > by inspection; and what testing has been done, e.g. compile tested only.
>
> Sure I'll add that to future patches that I send.
> This issue was reported by a prototype static analysis tool.
> And it is compile tested only.
Thanks, I think the including two lines above would work well.
>
> > I think it would be best to follow the idiomatic pattern and
> > introduce a ladder of goto statements to handle unwind on error.
> >
> > Something like this (compile tested only!):
> >
> > diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
> > @@ -1921,6 +1920,7 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
> > probe_alt_setting, vend_idx, cfg_used, *vcf, attr, cfg_found,
> > ep_addr, cmptbl[16], small_match, iso_packet_size, packet_size,
> > alt_used = 0;
> > + int err;
> >
> > vend_idx = 0xffff;
> > for (i = 0; hfcsusb_idtab[i].idVendor; i++) {
> > @@ -2101,20 +2101,28 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
> > if (!hw->ctrl_urb) {
> > pr_warn("%s: No memory for control urb\n",
> > driver_info->vend_name);
> > - kfree(hw);
> > - return -ENOMEM;
> > + err = -ENOMEM;
> > + goto err_free_urb;
> > }
> >
> > pr_info("%s: %s: detected \"%s\" (%s, if=%d alt=%d)\n",
> > hw->name, __func__, driver_info->vend_name,
> > conf_str[small_match], ifnum, alt_used);
> >
> > - if (setup_instance(hw, dev->dev.parent))
> > - return -EIO;
> > + if (setup_instance(hw, dev->dev.parent)) {
> > + err = -EIO;
> > + goto err_free_hw;
> > + }
> >
> > hw->intf = intf;
> > usb_set_intfdata(hw->intf, hw);
> > return 0;
> > +
> > +err_free_urb:
> > + usb_free_urb(hw->ctrl_urb);
> > +err_free_hw:
> > + kfree(hw);
> > + return err;
> > }
>
> In this case, since there are only two memory allocations and only two
> error paths involved, I would prefer keeping the frees in place. But I
> agree that for longer error paths the ladder of gotos would be better.
>
> Let me know. I can send an updated patch in the goto-ladder style, if
> you insist.
Insist is a strong word. But that is my preference.
Because even for two allocations this is the preferred style
for Networking code.
next prev parent reply other threads:[~2025-10-29 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 17:34 [PATCH net] isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() Abdun Nihaal
2025-10-28 12:32 ` Simon Horman
2025-10-28 16:38 ` Abdun Nihaal
2025-10-29 16:45 ` Simon Horman [this message]
2025-10-30 4:11 ` Abdun Nihaal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQJEkvtfmG-sEA3v@horms.kernel.org \
--to=horms@kernel.org \
--cc=isdn@linux-pingi.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nihaal@cse.iitm.ac.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).