netdev - Re: [BUG] use-after-free after removing UDC with USB Ethernet gadget

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]

Message-ID: <Y1eahQ66OcpsECNf@kroah.com>
Date:   Tue, 25 Oct 2022 10:12:53 +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 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?

> 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.

Is this now an expected use case of the kernel?  If so, patches are
welcome to address this in all gadget drivers.

thanks,

greg k-h