[PATCH v3] team: reject CAN and IEEE 802.15.4 devices in team_port_add

[PATCH v3] team: reject CAN and IEEE 802.15.4 devices in team_port_add

[Oliver Hartkopp]

From: Jiale Yao <yaojiale02@163.com>

Enslaving a CAN or IEEE 802.15.4 device (e.g. vxcan, wpan0) to a
team master triggers a NULL pointer dereference because these
device types use different Layer 2 architectures from Ethernet and
the team driver never initializes their private mid-layer data
structures.

Reject ARPHRD_CAN, ARPHRD_IEEE802154, and ARPHRD_IEEE802154_MONITOR
devices in team_port_add(), mirroring the existing CAN check already
present in the bonding driver since commit 8ba68464e478 ("bonding:
refuse to enslave CAN devices").

Link: https://lore.kernel.org/all/b58d98e0-8fe3-4e4e-b8a5-c1c7e647ccca@hartkopp.net/
Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
Assisted-by: Claude:deepseek-v4-pro
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
v3: [Hartkopp] fixed indention and compilation as reported by kernel test robot
---
 drivers/net/team/team_core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
index ca75f08e3c59..5f1708c2a344 100644
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1223,10 +1223,20 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
 		netdev_err(dev, "Device %s is loopback device. Loopback devices can't be added as a team port\n",
 			   portname);
 		return -EINVAL;
 	}
 
+	if (port_dev->type == ARPHRD_CAN ||
+	    port_dev->type == ARPHRD_IEEE802154 ||
+	    port_dev->type == ARPHRD_IEEE802154_MONITOR) {
+		NL_SET_ERR_MSG(extack,
+			       "CAN and IEEE 802.15.4 devices can't be added as a team port");
+		netdev_err(dev, "Device %s is CAN or IEEE 802.15.4. These device types 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 "
 				"of a team device\n", portname);
 		return -EBUSY;
-- 
2.53.0

Re: [PATCH v3] team: reject CAN and IEEE 802.15.4 devices in team_port_add

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH v3] team: reject CAN and IEEE 802.15.4 devices in team_port_add

[Oliver Hartkopp]

The issue was found by code inspection (LLM-assisted, see the
Assisted-by tag), following the syzbot report against the bonding
driver (syzbot+8ed98cbd0161632bce95), which was fixed by commit
8ba68464e478 ("bonding: refuse to enslave CAN devices").

team_setup_by_port() copies port_dev->type into the team device in
the same way, so a team master with a vxcan port ends up as an
ARPHRD_CAN device without can_ml_priv, and runs into the same
NULL pointer dereference (e.g. via isotp_release() ->
can_rx_unregister()).

The same class of problem (non-CAN netdevs claiming ARPHRD_CAN
without CAN ml_priv) was already hit by syzbot in the CAN core and
mitigated there, see 8aa59e355949 ("can: af_can: fix NULL pointer
dereference in can_rx_register()") and 0acc442309a0 ("can: af_can:
fix NULL pointer dereference in can_rcv_filter",
syzbot+2d7f58292cb5b29eb5ad), both with bonding/tun.

The IEEE 802.15.4 types were added by analogy during review.

Best regards,
Oliver

On 13.10.26 10:39, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.