Re: [PATCH net-next v5 2/4] net: dsa: mxl862xx: move phylink stubs to mxl862xx-phylink.c

[Daniel Golle <daniel@makrotopia.org>]

On Thu, Jun 11, 2026 at 02:07:51PM +0100, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: dsa: mxl862xx: move phylink stubs to mxl862xx-phylink.c
> 
> Move the phylink MAC operations and get_caps callback from mxl862xx.c
> into a dedicated mxl862xx-phylink.c file. This prepares for the SerDes
> PCS implementation which adds substantial phylink/PCS code.
> 
> > diff --git a/drivers/net/dsa/mxl862xx/mxl862xx.c b/drivers/net/dsa/mxl862xx/mxl862xx.c
> > index 2f22adedfbf67..a193f3c07d359 100644
> > --- a/drivers/net/dsa/mxl862xx/mxl862xx.c
> > +++ b/drivers/net/dsa/mxl862xx/mxl862xx.c
> 
> [ ... ]
> 
> [Severity: Critical]
> This is a pre-existing issue, but the crc_err_work can execute after
> dsa_unregister_switch(), leading to a use-after-free of ds->dst and
> dsa_port structures.
> 
> In mxl862xx_remove(), dsa_unregister_switch() is called before the
> asynchronous crc_err_work is cancelled via mxl862xx_host_shutdown():
> 
> drivers/net/dsa/mxl862xx/mxl862xx.c:mxl862xx_remove() {
> 	...
> 	dsa_unregister_switch(ds);
> 
> 	mxl862xx_host_shutdown(priv);
> 	...
> }
> 
> dsa_unregister_switch() tears down the DSA tree, frees all dsa_port
> objects, and drops the reference to ds->dst.
> 
> If mxl862xx_crc_err_work_fn executes concurrently or after
> dsa_unregister_switch() has returned, it traverses already freed
> dsa_port entries:
> 
> drivers/net/dsa/mxl862xx/mxl862xx-host.c:mxl862xx_crc_err_work_fn() {
> 	...
> 	dsa_switch_for_each_cpu_port(dp, priv->ds)
> 		dev_close(dp->conduit);
> 	...
> }
> 
> Could this order in mxl862xx_remove() result in a use-after-free, and
> should mxl862xx_host_shutdown() be called before dsa_unregister_switch()?

To really address this a guard in mxl862xx_host_shutdown() will be
needed. I'd rather do this in a separate Fixes:-patch targetting 'net'
rather than in this series targetting 'net-next', right?