[PATCH] team: reject ARPHRD_CAN devices in team_port_add

[PATCH] team: reject ARPHRD_CAN devices in team_port_add

[Jiale Yao]

Enslaving a CAN device (e.g. vxcan) to a team master triggers a
NULL pointer dereference in can_rx_unregister() inside
net/can/af_can.c.

During team_port_add(), the code only checks IFF_LOOPBACK but
does not reject ARPHRD_CAN devices.  After passing this gate,
team_dev_type_check_change() calls team_setup_by_port() which
sets dev->type = port_dev->type, adopting the CAN type for the
team device.  However, CAN devices operate on a fundamentally
different Layer 2 architecture, relying on the CAN mid-layer
private data structure (can_ml_priv) instead of standard
Ethernet structures.  Since the team driver never initializes
can_ml_priv, subsequent CAN subsystem operations -- such as
closing an ISOTP socket bound to the team interface via
isotp_release() -- reach can_rx_unregister() which dereferences
the NULL can_ml_priv, causing a kernel crash.

The bonding driver already rejects CAN devices since commit
8ba68464e478 ("bonding: refuse to enslave CAN devices").
Team, as a sibling aggregation path, needs the same protection.

Fix this by adding an explicit ARPHRD_CAN check in
team_port_add(), directly after the IFF_LOOPBACK guard,
consistent with the approach taken in bond_enslave().

Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
Assisted-by: Claude:deepseek-v4-pro
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/net/team/team_core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
index feaa75fbf8fc..38f88a836010 100644
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1224,6 +1224,13 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
 		return -EINVAL;
 	}
 
+	if (port_dev->type == ARPHRD_CAN) {
+		NL_SET_ERR_MSG(extack, "CAN device can't be added as a team port");
+		netdev_err(dev, "Device %s is CAN device. CAN devices can't be added as a team port\n",
+			   portname);
+		return -EINVAL;
+	}
+
 	if (netif_is_team_port(port_dev)) {
 		NL_SET_ERR_MSG(extack, "Device is already a port of a team device");
 		netdev_err(dev, "Device %s is already a port "
-- 
2.34.1

Re: [PATCH] team: reject ARPHRD_CAN devices in team_port_add

[Jakub Kicinski]

On Thu, 23 Jul 2026 12:00:32 +0800 Jiale Yao wrote:
> Enslaving a CAN device (e.g. vxcan) to a team master triggers a
> NULL pointer dereference in can_rx_unregister() inside
> net/can/af_can.c.

Gemini review says that similar issue is possible with
ARPHRD_IEEE802154 devices, could you double check that,
see if there are any others, and all these in a single
patch?
-- 
pw-bot: cr

Re:Re: [PATCH] team: reject ARPHRD_CAN devices in team_port_add

[jiale yao]

Hi

Sure, I will check, and send v2 patch if there are any others.

Jiale Yao

At 2026-07-28 09:24:47, "Jakub Kicinski" <kuba@kernel.org> wrote:
>On Thu, 23 Jul 2026 12:00:32 +0800 Jiale Yao wrote:
>> Enslaving a CAN device (e.g. vxcan) to a team master triggers a
>> NULL pointer dereference in can_rx_unregister() inside
>> net/can/af_can.c.
>
>Gemini review says that similar issue is possible with
>ARPHRD_IEEE802154 devices, could you double check that,
>see if there are any others, and all these in a single
>patch?
>-- 
>pw-bot: cr

Re: [PATCH] team: reject ARPHRD_CAN devices in team_port_add

[Oliver Hartkopp]

On 23.07.26 06:00, Jiale Yao wrote:
> Enslaving a CAN device (e.g. vxcan) to a team master triggers a
> NULL pointer dereference in can_rx_unregister() inside
> net/can/af_can.c.
> 
> During team_port_add(), the code only checks IFF_LOOPBACK but
> does not reject ARPHRD_CAN devices.  After passing this gate,
> team_dev_type_check_change() calls team_setup_by_port() which
> sets dev->type = port_dev->type, adopting the CAN type for the
> team device.  However, CAN devices operate on a fundamentally
> different Layer 2 architecture, relying on the CAN mid-layer
> private data structure (can_ml_priv) instead of standard
> Ethernet structures.  Since the team driver never initializes
> can_ml_priv, subsequent CAN subsystem operations -- such as
> closing an ISOTP socket bound to the team interface via
> isotp_release() -- reach can_rx_unregister() which dereferences
> the NULL can_ml_priv, causing a kernel crash.
> 
> The bonding driver already rejects CAN devices since commit
> 8ba68464e478 ("bonding: refuse to enslave CAN devices").
> Team, as a sibling aggregation path, needs the same protection.
> 
> Fix this by adding an explicit ARPHRD_CAN check in
> team_port_add(), directly after the IFF_LOOPBACK guard,
> consistent with the approach taken in bond_enslave().
> 
> Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
> Assisted-by: Claude:deepseek-v4-pro
> Signed-off-by: Jiale Yao <yaojiale02@163.com>

Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>

I did not know that the team driver had the same approach.
Thanks for catching this!

Best regards,
Oliver

> ---
>   drivers/net/team/team_core.c | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
> index feaa75fbf8fc..38f88a836010 100644
> --- a/drivers/net/team/team_core.c
> +++ b/drivers/net/team/team_core.c
> @@ -1224,6 +1224,13 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
>   		return -EINVAL;
>   	}
>   
> +	if (port_dev->type == ARPHRD_CAN) {
> +		NL_SET_ERR_MSG(extack, "CAN device can't be added as a team port");
> +		netdev_err(dev, "Device %s is CAN device. CAN devices can't be added as a team port\n",
> +			   portname);
> +		return -EINVAL;
> +	}
> +
>   	if (netif_is_team_port(port_dev)) {
>   		NL_SET_ERR_MSG(extack, "Device is already a port of a team device");
>   		netdev_err(dev, "Device %s is already a port "