netdev - Re: [PATCH v2 2/2] phy: mdio: fix memory leak

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:   Wed, 29 Sep 2021 09:22:26 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Pavel Skripkin <paskripkin@...il.com>
Cc:     andrew@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk,
        davem@...emloft.net, kuba@...nel.org, buytenh@...vell.com,
        afleming@...escale.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        syzbot+398e7dc692ddbbb4cfec@...kaller.appspotmail.com
Subject: Re: [PATCH v2 2/2] phy: mdio: fix memory leak

On Tue, Sep 28, 2021 at 11:40:15PM +0300, Pavel Skripkin wrote:
> Syzbot reported memory leak in MDIO bus interface, the problem was in
> wrong state logic.
> 
> MDIOBUS_ALLOCATED indicates 2 states:
> 	1. Bus is only allocated
> 	2. Bus allocated and __mdiobus_register() fails, but
> 	   device_register() was called
> 
> In case of device_register() has been called we should call put_device()
> to correctly free the memory allocated for this device, but mdiobus_free()
> calls just kfree(dev) in case of MDIOBUS_ALLOCATED state
> 
> To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED
> _before_ calling device_register(), because put_device() should be
> called even in case of device_register() failure.
> 
> Link: https://lore.kernel.org/netdev/YVMRWNDZDUOvQjHL@shell.armlinux.org.uk/ 
> Fixes: 46abc02175b3 ("phylib: give mdio buses a device tree presence")
> Reported-and-tested-by: syzbot+398e7dc692ddbbb4cfec@...kaller.appspotmail.com
> Signed-off-by: Pavel Skripkin <paskripkin@...il.com>

Thanks!

Reviewed-by: Dan Carpenter <dan.carpenter@...cle.com>

regards,
dan carpenter