netdev - Re: [PATCH v2 1/2] Revert "net: mdiobus: Fix memory leak in __mdiobus

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: <cf252f69-bc42-3d4d-3967-3f58f8607e93@windriver.com>
Date:   Wed, 29 Sep 2021 14:32:49 +0800
From:   "Xu, Yanfei" <yanfei.xu@...driver.com>
To:     Pavel Skripkin <paskripkin@...il.com>, andrew@...n.ch,
        hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
        kuba@...nel.org, buytenh@...vell.com, afleming@...escale.com,
        dan.carpenter@...cle.com
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] Revert "net: mdiobus: Fix memory leak in
 __mdiobus_register"



On 9/29/21 4:39 AM, Pavel Skripkin wrote:
> This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.
> 
> This patch is correct in the sense that we_should_  call device_put() in
> case of device_register() failure, but the problem in this code is more
> vast.
> 
> We need to set bus->state to UNMDIOBUS_REGISTERED before calling
> device_register() to correctly release the device in mdiobus_free().
> This patch prevents us from doing it, since in case of device_register()
> failure put_device() will be called 2 times and it will cause UAF or
> something else.
> 
> Also, Reported-by: tag in revered commit was wrong, since syzbot
> reported different leak in same function.
> 
> Link:https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
> Cc: Yanfei Xu<yanfei.xu@...driver.com>
> Signed-off-by: Pavel Skripkin<paskripkin@...il.com>
> ---
> 
> Changes in v2:
>          Added this revert


Acked-by: Yanfei Xu<yanfei.xu@...driver.com>

Thanks,
Yanfei