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

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hi Hangbin,

On 18.08.26 12:12, Hangbin Liu wrote:
> On Sat, Aug 15, 2026 at 07:23:35PM +0200, Oliver Hartkopp wrote:
>>
>>
>> On 15.08.26 18:00, Stephen Hemminger wrote:
>>> On Sat, 15 Aug 2026 17:39:38 +0200
>>> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>>
>>>> +static inline bool netdev_has_ml_priv(struct net_device *dev)
>>>> +{
>>>> +	return (dev->ml_priv != NULL);
>>>> +}
>>>> +
>>>
>>> Minor suggestion: use const and drop unneeded parens
>>>
>>> static inline bool netdev_has_ml_priv(const struct net_device *dev)
>>> {
>>> 	return dev->ml_priv != NULL;
>>> }
>>>
>>>
>>
>> Good point!
>>
>> Will wait for some more feedback before sending a v2.
> 
> 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.

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).

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

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."

??

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.

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.

For that reason

static inline bool netdev_has_ml_priv(struct net_device *dev)
{
	return dev->ml_priv != NULL;
}

seems to be the safe solution that would point out potential problems 
with those drivers immediately.

Best regards,
Oliver