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: <20210513080957.GS1336@shell.armlinux.org.uk>
Date:   Thu, 13 May 2021 09:09:57 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     andrew@...n.ch, hkallweit1@...il.com, davem@...emloft.net,
        kuba@...nel.org, david.daney@...ium.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] net: mdio: Fix a double free issue in the .remove
 function

On Thu, May 13, 2021 at 08:29:01AM +0200, Christophe JAILLET wrote:
> Le 12/05/2021 à 23:44, Russell King - ARM Linux admin a écrit :
> > On Wed, May 12, 2021 at 11:35:38PM +0200, Christophe JAILLET wrote:
> > > 'bus->mii_bus' have been allocated with 'devm_mdiobus_alloc_size()' in the
> > > probe function. So it must not be freed explicitly or there will be a
> > > double free.
> > > 
> > > Remove the incorrect 'mdiobus_free' in the remove function.
> > 
> > Yes, this looks correct, thanks.
> > 
> > Reviewed-by: Russell King <rmk+kernel@...linux.org.uk>
> > 
> > However, there's another issue in this driver that ought to be fixed.
> > 
> > If devm_mdiobus_alloc_size() succeeds, but of_mdiobus_register() fails,
> > we continue on to the next bus (which I think is reasonable.) We don't
> > free the bus.
> > 
> > When we come to the remove method however, we will call
> > mdiobus_unregister() on this existent but not-registered bus. Surely we
> > don't want to do that?
> > 
> 
> Hmmm, I don't agree here.
> 
> 'nexus' is 'kzalloc()'ed.
> So the pointers in 'buses[]' are all NULL by default.
> We set 'nexus->buses[i] = bus' only when all functions that can fail in the
> loop have been called. (the very last 'break' is when the array is full)
> 
> And in the remove function, we have:
> 	struct cavium_mdiobus *bus = nexus->buses[i];
> 	if (!bus)
> 		continue;
> 
> So, this looks safe to me.

It isn't safe. Please look closer.

        device_for_each_child_node(&pdev->dev, fwn) {
                mii_bus = devm_mdiobus_alloc_size(&pdev->dev, sizeof(*bus));
                if (!mii_bus)
                        break;
                bus = mii_bus->priv;
                bus->mii_bus = mii_bus;

                nexus->buses[i] = bus;

This succeeds and sets nexus->buses[i] to a non-NULL value.

                err = of_mdiobus_register(bus->mii_bus, node);
                if (err)
                        dev_err(&pdev->dev, "of_mdiobus_register failed\n");

                dev_info(&pdev->dev, "Added bus at %llx\n", r.start);
                if (i >= ARRAY_SIZE(nexus->buses))
                        break;
        }

If of_mdiobus_register() fails, the bus is not registered, and we just
move on to the next bus, leaving nexus->buses[i] set to a non-NULL
value.

If we now look at the remove code:

        for (i = 0; i < ARRAY_SIZE(nexus->buses); i++) {
                struct cavium_mdiobus *bus = nexus->buses[i];

                if (!bus)
                        continue;

                mdiobus_unregister(bus->mii_bus);

nexus->buses[i] is non-NULL, but the bus is _not_ registered. We end up
calling mdiobus_unregister() on an allocated but _unregistered_ bus.
This is a bug.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ