Re: [bug report] Potential order bug in 'drivers/net/can/vxcan.c', primarily in 'vxcan_dellink()'

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hello Ginger,

On 24.04.26 17:24, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential order bug within
> the ' drivers/net/can' subsystem, more specifically, in '
> drivers/net/can/vxcan.c'.
> 
> Kernel version: long-term kernel v6.18.9
> 
> Potential issue:
> T0:
> vxcan_dellink
>      --> RCU_INIT_POINTER(priv->peer, NULL);
>      --> unregister_netdevice_queue(dev, head);
> 
> In T0, the priv->peer field is nullified before the device is
> unregistered from the kernel in 'unregister_netdevice_queue()'.
> Considering that many other kernel functions rely on the existence of
> the netdev and dereferences 'priv->peer', e.g., vxcan_open() and
> vxcan_xmit(), it is possible to cause null pointer deref in concurrent
> executions.
> 

The code in

https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/can/vxcan.c#L282

is copied from

https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/veth.c#L1931

which contains the following comment:

	/* Note : dellink() is called from default_device_exit_batch(),
	 * before a rcu_synchronize() point. The devices are guaranteed
	 * not being freed before one RCU grace period.
	 */
	RCU_INIT_POINTER(priv->peer, NULL);
	unregister_netdevice_queue(dev, head);

So I'm pretty sure this case is addressed.

Best regards,
Oliver