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] [day] [month] [year] [list]
Date:   Tue, 25 Oct 2022 12:29:46 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Peter Chen <peter.chen@...nel.org>,
        Felipe Balbi <balbi@...nel.org>, johannes.berg@...el.com,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>
Subject: Re: [BUG] use-after-free after removing UDC with USB Ethernet gadget

On Tue, Oct 25, 2022 at 11:28:24AM +0200, Ahmad Fatoum wrote:
> Hello Greg,
> 
> On 25.10.22 10:12, Greg KH wrote:
> > On Tue, Oct 25, 2022 at 08:54:58AM +0200, Ahmad Fatoum wrote:
> >> Hi everybody,
> >>
> >> I am running v6.0.2 and can reliably trigger a use-after-free by allocating
> >> a USB gadget, binding it to the chipidea UDC and the removing the UDC.
> > 
> > How do you remove the UDC?
> 
> I originally saw this while doing reboot -f on the device. The imx_usb driver's
> shutdown handler is equivalent to the remove handler and that removes the UDC.

That's odd, why isn't the network device being shutdown first?  The tree
of devices should be walked in child-first order and tear it down
correctly.

> It could also be triggered with:
> 
>   echo ci_hdrc.0 > /sys/class/udc/ci_hdrc.0/device/driver/unbind

Yes, manual removal as root can cause problems as I said.  The code was
never designed to handle this.

> >> The network interface is not removed, but the chipidea SoC glue driver will
> >> remove the platform_device it had allocated in the probe, which is apparently
> >> the parent of the network device. When rtnl_fill_ifinfo runs, it will access the
> >> device parent's name for IFLA_PARENT_DEV_NAME, which is now freed memory.
> > 
> > The gadget removal logic is almost non-existant for most of the function
> > code.  See Lee's patch to try to fix up the f_hid.c driver last week as
> > one example.  I imagine they all have this same issue as no one has ever
> > tried the "remove the gadget device from the running Linux system"
> > before as it was not an expected use case.
> 
> I see.
> 
> FTR: https://lore.kernel.org/all/20221017112737.230772-1-lee@kernel.org/
>  
> > Is this now an expected use case of the kernel?  If so, patches are
> > welcome to address this in all gadget drivers.
> 
> I don't really care for unbinding via sysfs. I want to avoid the
> use-after-free on reboot/shutdown. See the last splat in my original mail.

Maybe try to figure out what is tearing down the bus's devices in the
incorrect order?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ