linux-kernel - Re: [PATCH] net: ethernet: Fix memleak in ethoc

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, 23 Dec 2020 14:17:29 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc:     Dinghao Liu <dinghao.liu@....edu.cn>, kjlu@....edu,
        "David S. Miller" <davem@...emloft.net>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Arnd Bergmann <arnd@...db.de>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe



On 12/23/2020 1:11 PM, Jakub Kicinski wrote:
> On Wed, 23 Dec 2020 22:00:44 +0100 Andrew Lunn wrote:
>> On Wed, Dec 23, 2020 at 12:32:18PM -0800, Jakub Kicinski wrote:
>>> On Wed, 23 Dec 2020 16:33:04 +0100 Andrew Lunn wrote:  
>>>> On Wed, Dec 23, 2020 at 07:06:12PM +0800, Dinghao Liu wrote:  
>>>>> When mdiobus_register() fails, priv->mdio allocated
>>>>> by mdiobus_alloc() has not been freed, which leads
>>>>> to memleak.
>>>>>
>>>>> Signed-off-by: Dinghao Liu <dinghao.liu@....edu.cn>    
>>>>
>>>> Fixes: bfa49cfc5262 ("net/ethoc: fix null dereference on error exit path")
>>>>
>>>> Reviewed-by: Andrew Lunn <andrew@...n.ch>  
>>>
>>> Ooof, I applied without looking at your email and I added:
>>>
>>> Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core")  
>>
>> [Goes and looks deeper]
>>
>> Yes, commit e7f4dc3536a4 looks like it introduced the original
>> problem. bfa49cfc5262 just moved to code around a bit.
>>
>> Does patchwork not automagically add Fixes: lines from full up emails?
>> That seems like a reasonable automation.
> 
> Looks like it's been a TODO for 3 years now:
> 
> https://github.com/getpatchwork/patchwork/issues/151

It was proposed before, but rejected. You can have your local patchwork
admin take care of that for you though and add custom tags:

https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html
-- 
Florian