Re: [PATCH net] net: do not bond/team netdevices which use ml_priv

[Hangbin Liu <hangbin.liu@linux.dev>]

Hi Oliver,
On Tue, Aug 18, 2026 at 03:25:36PM +0200, Oliver Hartkopp wrote:
> Hi Hangbin,
> > Hi Oliver,
> > 
> > Sashiko gives some feed back[1], would you please check it?
> > 
> > [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260815153938.187073-1-socketcan%40hartkopp.net
> > 
> 
> Unfortunately the AI bot review did not create a proper answer, so that I
> would be able to answer in-line.

Thanks for your reply.

> 
> Sashiko says:
> 
> "Is this test too broad for plain Ethernet slaves?
> netdev_has_ml_priv() only looks at dev->ml_priv, not at dev->ml_priv_type,
> so it matches any driver that stashes a private pointer there, including
> ARPHRD_ETHER NICs that were never involved in the CAN crash."
> 
> and later also points out potential problems that could arise with tun.
> 
> Today only the CAN subsystem properly sets dev->ml_priv_type. Other users
> simply grab dev->ml_priv for their needs (inkognito).

Yes

> 
> To me the question is whether bonding/teaming and now also tunneling code
> takes care about the mid-layer private pointer dev->ml_priv?!?

AFAIK, no.

> 
> The fact that the issues have been found by syzbot for CAN devices might be
> through to the fact that the virtual CAN interface (vcan) can be created by
> netlink commands and can be easily used in test setups.
> 
> So what would happen, if the same tests with bonding/teaming/tunneling would
> be done with real hardware drivers as the mentioned "direct ml_priv writers
> still in tree at this revision:
> 
>   drivers/s390/net/qeth_core_main.c:qeth_alloc_netdev()
>       dev->ml_priv = card;
>   drivers/net/ethernet/chelsio/cxgb/cxgb2.c:init_one()
>       netdev->ml_priv = adapter;
>   drivers/net/wan/hdlc_fr.c:fr_add_pvc()
>       dev->ml_priv = pvc;
> 
> plus drivers/net/ethernet/i825xx/82596.c, drivers/s390/net/ctcm_main.c,
> the libertas main.c/mesh.c paths and
> drivers/net/wireless/microchip/wilc1000/netdev.c."
> 
> ??

I'm not worry about cxgb2 or 82596, which are too old. But s390 qeth is
still actively maintained (Cc the maintainers). Can we block them directly?

> 
> If bonding/teaming/tunneling might accidentally overwrite dev->ml_priv we
> have to block all those devices. No matter if it is CAN or whatever ethernet
> device.

How would bonding modify dev->ml_priv?

> 
> And this it what this patch aims for.
> 
> So either the users were lucky so far or they never used
> bonding/teaming/tunneling on these devices? I don't know.
> 
> But it definitely looks like we should make a safe move to block all ml_priv
> using devices.
> 
> Most of the referenced drivers are 20+ years old! Only
> drivers/net/wireless/microchip/wilc1000/netdev.c is about 11 years old and
> moved from staging into mainline in 2020. The use of ml_priv is a left-over
> from the former out out tree development. The wilc1000 drivers does not use
> the existing infrastructure in the correct way. In all cases this wifi
> driver and all the ancient ethernet drivers should (and can) be implemented
> without using the ml_priv pointer today.
> 
> When there are (unlikely) real users of those (ancient) drivers together
> with bonding/teaming/tunneling those drivers should be changed in a way that
> they do not need dev->ml_priv anymore.

No need to fix the ancient driver at present.

Thanks
Hangbin