mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: David Miller <davem@davemloft.net>
Cc: changbinx.du@intel.com, oliver@neukum.org,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
Date: Wed, 30 Oct 2013 09:38:18 +0100	[thread overview]
Message-ID: <87y55bduh1.fsf@nemi.mork.no> (raw)
In-Reply-To: <20131029.223823.1852248673779937090.davem@davemloft.net> (David Miller's message of "Tue, 29 Oct 2013 22:38:23 -0400 (EDT)")

David Miller <davem@davemloft.net> writes:

> The problem is in cdc_ncm_bind_common().
>
> It seems to leave dangling interface data pointers in some cases, and
> then branches just to "error" so that they don't get cleared back out.

Sorry, but I fail to see this as well.  I see one "return" and two "goto
error", but all are well before any intfdata pointer is set:

    364         ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
    365         if (!ctx)
    366                 return -ENOMEM;
    367 
[..]
    453         /* check if we got everything */
    454         if ((ctx->control == NULL) || (ctx->data == NULL) ||
    455             ((!ctx->mbim_desc) && ((ctx->ether_desc == NULL) || (ctx->control != intf))))
    456                 goto error;
    457 
    458         /* claim data interface, if different from control */
    459         if (ctx->data != ctx->control) {
    460                 temp = usb_driver_claim_interface(driver, ctx->data, dev);
    461                 if (temp)
    462                         goto error;
    463         }
[..]
    490         usb_set_intfdata(ctx->data, dev);
    491         usb_set_intfdata(ctx->control, dev);
    492         usb_set_intfdata(ctx->intf, dev);
[..]
    510         return 0;
    511 
    512 error2:
    513         usb_set_intfdata(ctx->control, NULL);
    514         usb_set_intfdata(ctx->data, NULL);
    515         if (ctx->data != ctx->control)
    516                 usb_driver_release_interface(driver, ctx->data);
    517 error:
    518         cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
    519         dev->data[0] = 0;
    520         dev_info(&dev->udev->dev, "bind() failure\n");
    521         return -ENODEV;
    522 }
 

This could (and given this thread, probably should) certainly be
refactored and cleaned up a bit.  But I do not see how it leaves any
dangling pointers.  The pointers are only set near the end of the
function, and the only exit points after that are either success or
through the "error2" label.

Side note: It is definitely confusing that we set 3 pointers, but only
clean up 2.  The reason is that there are never more than 2 interfaces
involved here. We always have ctx->intf == ctx->control.  I'd really
like to get rid of that redundant ctx->intf pointer.  That's one issue
to cleanup throughout this driver.



Bjørn

      reply	other threads:[~2013-10-30  8:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29  3:30 Du, ChangbinX
2013-10-29  8:41 ` Bjørn Mork
2013-10-31  3:06   ` Du, ChangbinX
2013-10-31  9:02     ` Bjørn Mork
2013-10-30  2:38 ` David Miller
2013-10-30  8:38   ` Bjørn Mork [this message]

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=87y55bduh1.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=changbinx.du@intel.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oliver@neukum.org \
    /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

Powered by JetHome