linux-kernel - Re: [PATCH 0/8] can: usb: remove all usb_set_intfdata(intf, NULL) in drivers' disconnect()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 8 Dec 2022 11:28:24 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     Oliver Neukum <oneukum@...e.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can@...r.kernel.org, Wolfgang Grandegger <wg@...ndegger.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Frank Jungclaus <frank.jungclaus@....eu>, socketcan@....eu,
        Yasushi SHOJI <yashi@...cecubics.com>,
        Stefan Mätje <stefan.maetje@....eu>,
        Hangyu Hua <hbh25y@...il.com>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Peter Fink <pfink@...ist-es.de>,
        Jeroen Hofstee <jhofstee@...tronenergy.com>,
        Christoph Möhring <cmoehring@...ist-es.de>,
        John Whittington <git@...engineering.co.uk>,
        Vasanth Sadhasivan <vasanth.sadhasivan@...sara.com>,
        Jimmy Assarsson <extja@...ser.com>,
        Anssi Hannula <anssi.hannula@...wise.fi>,
        Pavel Skripkin <paskripkin@...il.com>,
        Stephane Grosjean <s.grosjean@...k-system.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        Julia Lawall <Julia.Lawall@...ia.fr>,
        Dongliang Mu <dzm91@...t.edu.cn>,
        Sebastian Haas <haas@...-wuensche.com>,
        Maximilian Schneider <max@...neidersoft.net>,
        Daniel Berglund <db@...ser.com>,
        Olivier Sobrie <olivier@...rie.be>,
        Remigiusz Kołłątaj 
        <remigiusz.kollataj@...ica.com>,
        Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-systems.com>,
        Martin Elshuber <martin.elshuber@...obroma-systems.com>,
        Bernd Krumboeck <b.krumboeck@...il.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH 0/8] can: usb: remove all usb_set_intfdata(intf, NULL) in
 drivers' disconnect()

On Fri, Dec 09, 2022 at 12:44:51AM +0900, Vincent MAILHOL wrote:
> On Thu. 8 Dec. 2022 at 20:04, Oliver Neukum <oneukum@...e.com> wrote:

> > >> which is likely, then please also remove checks like this:
> > >>
> > >>          struct ems_usb *dev = usb_get_intfdata(intf);
> > >>
> > >>          usb_set_intfdata(intf, NULL);
> > >>
> > >>          if (dev) {
> >
> > Here. If you have a driver that uses usb_claim_interface().
> > You need this check or you unregister an already unregistered
> > netdev.
> 
> Sorry, but with all my best intentions, I still do not get it. During
> the second iteration, inft is NULL and:

No, intf is never NULL.  Rather, the driver-specific pointer stored in 
intfdata may be NULL.

You seem to be confusing intf with intfdata(intf).

>         /* equivalent to dev = intf->dev.data. Because intf is NULL,
>          * this is a NULL pointer dereference */
>         struct ems_usb *dev = usb_get_intfdata(intf);

So here dev will be NULL when the second interface's disconnect routine 
runs, because the first time through the routine sets the intfdata to 
NULL for both interfaces:

	USB core calls ->disconnect(intf1)

		disconnect routine sets intfdata(intf1) and 
		intfdata(intf2) both to NULL and handles the
		disconnection

	USB core calls ->disconnect(intf2)

		disconnect routine sees that intfdata(intf2) is
		already NULL, so it knows that it doesn't need
		to do anything more.

As you can see in this scenario, neither intf1 nor intf2 is ever NULL.

>         /* OK, intf is already NULL */
>         usb_set_intfdata(intf, NULL);
> 
>         /* follows a NULL pointer dereference so this is undefined
>          * behaviour */
>        if (dev) {
> 
> How is this a valid check that you entered the function for the second
> time? If intf is the flag, you should check intf, not dev? Something
> like this:

intf is not a flag; it is the argument to the function and is never 
NULL.  The flag is the intfdata.

>         struct ems_usb *dev;
> 
>         if (!intf)
>                 return;
> 
>         dev = usb_get_intfdata(intf);
>         /* ... */
> 
> I just can not see the connection between intf being NULL and the if
> (dev) check. All I see is some undefined behaviour, sorry.

Once you get it straightened out in your head, you will understand.

Alan Stern