[PATCH net v4] team: reject CAN, IEEE 802.15.4 and 6LoWPAN devices in team_port_add

[PATCH net v4] team: reject CAN, IEEE 802.15.4 and 6LoWPAN devices in team_port_add

[Oliver Hartkopp]

From: Jiale Yao <yaojiale02@163.com>

When the first port has a non-Ethernet type, team_setup_by_port()
copies port_dev->type to the team device while netdev_priv() of the
team device still holds a struct team. Several L2 stacks identify their
devices by dev->type alone and then access type specific data that the
team driver never sets up:

- CAN protocols rely on the CAN mid-layer private data (ml_priv)
- IEEE 802.15.4 code dereferences ieee802154_ptr and the mlme ops in
  ml_priv
- the 6LoWPAN netdev notifier writes through lowpan_dev(dev) on
  NETDEV_DOWN and reads it on NETDEV_UP/NETDEV_CHANGE

Enslaving such a device (e.g. vxcan, wpan0, lowpan0) therefore leads to
NULL pointer dereferences or to writes into struct team.

Reject ARPHRD_CAN, ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR and
ARPHRD_6LOWPAN devices in team_port_add(). The bonding driver has
rejected CAN devices 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>
---
v4: [Hartkopp] also reject ARPHRD_6LOWPAN as reported by Sashiko AI
    review, reworded commit message (bonding only rejects CAN)
v3: [Hartkopp] fixed indention and compilation as reported by kernel test robot
---
 drivers/net/team/team_core.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1223,10 +1223,21 @@ 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 ||
+	    port_dev->type == ARPHRD_6LOWPAN) {
+		NL_SET_ERR_MSG(extack,
+			       "CAN, IEEE 802.15.4 and 6LoWPAN devices can't be added as a team port");
+		netdev_err(dev, "Device %s is CAN, IEEE 802.15.4 or 6LoWPAN. 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 net v4] team: reject CAN, IEEE 802.15.4 and 6LoWPAN 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.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

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 net v4] team: reject CAN, IEEE 802.15.4 and 6LoWPAN 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 and 6LoWPAN types were added by analogy during review.

Best regards,
Oliver

On 14.10.26 16:43, 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.
> 
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
> 
> 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.