linux-kernel - Re: [PATCH net] net: phy: leds: 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]

Message-ID: <CALW65jaAMpUSZnezmFB+gA6=BUaPkr6Afuhs5wkv0yyv+7XMrA@mail.gmail.com>
Date: Thu, 17 Apr 2025 15:59:20 +0800
From: Qingfang Deng <dqfext@...il.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, 
	Russell King <linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>, Nathan Sullivan <nathan.sullivan@...com>, 
	Josh Cartwright <josh.cartwright@...com>, Zach Brown <zach.brown@...com>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Chuanhong Guo <gch981213@...il.com>, 
	Qingfang Deng <qingfang.deng@...lower.com.cn>, Hao Guan <hao.guan@...lower.com.cn>
Subject: Re: [PATCH net] net: phy: leds: fix memory leak

Hi Maxime,

On Thu, Apr 17, 2025 at 3:38 PM Maxime Chevallier
<maxime.chevallier@...tlin.com> wrote:
>
> On Thu, 17 Apr 2025 11:25:56 +0800
> Qingfang Deng <dqfext@...il.com> wrote:
>
> > From: Qingfang Deng <qingfang.deng@...lower.com.cn>
> >
> > A network restart test on a router led to an out-of-memory condition,
> > which was traced to a memory leak in the PHY LED trigger code.
> >
> > The root cause is misuse of the devm API. The registration function
> > (phy_led_triggers_register) is called from phy_attach_direct, not
> > phy_probe, and the unregister function (phy_led_triggers_unregister)
> > is called from phy_detach, not phy_remove. This means the register and
> > unregister functions can be called multiple times for the same PHY
> > device, but devm-allocated memory is not freed until the driver is
> > unbound.
>
> Are there historical reasons for the triggers not to be registered at
> probe time ? I agree with your analysis otherwise.

I'm not sure exactly, but both register and unregister are called
under a condition:

-  if (!phydev->is_on_sfp_module)

Which may not be available at probe time.


>
> Maxime