[PATCH] bonding: reject IEEE 802.15.4 and 6LoWPAN devices in bond_enslave

[PATCH] bonding: reject IEEE 802.15.4 and 6LoWPAN devices in bond_enslave

[Kalpesh Solanki]

When the first non-Ethernet slave is enslaved to a bond,
bond_setup_by_slave() copies slave_dev->type to the bond device.
However, the bonding driver does not set up subsystem-specific
mid-layer contexts or private structures:

1. IEEE 802.15.4 routines (such as ieee802154_llsec_dump_table(),
   nl-phy.c, and socket callbacks) identify WPAN devices by dev->type
   alone and unconditionally dereference dev->ieee802154_ptr and
   dev->ml_priv (ieee802154_mlme_ops). Because bonding never allocates
   these, this results in a NULL pointer dereference.

2. The 6LoWPAN netdevice notifier (lowpan_event()) identifies devices
   by dev->type == ARPHRD_6LOWPAN and treats netdev_priv(dev) as
   struct lowpan_dev. On a bond master, netdev_priv() is struct bonding,
   so writes to lowpan_dev(dev)->ctx.table flags on events like
   NETDEV_DOWN corrupt the bonding driver's private state.

The team driver closed an identical gap in commit 9043be310c6a ("team:
reject CAN, IEEE 802.15.4 and 6LoWPAN devices in team_port_add"). Bonding
previously only blocked CAN devices in commit 8ba68464e478 ("bonding:
refuse to enslave CAN devices").

Reject ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR, and ARPHRD_6LOWPAN
devices in bond_enslave().

Fixes: 8ba68464e478 ("bonding: refuse to enslave CAN devices")
Signed-off-by: Kalpesh Solanki <skalpesh942@gmail.com>
---
 drivers/net/bonding/bond_main.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 7019e5d8fdc..b3b003e39b2 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1894,9 +1894,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
 	struct sockaddr_storage ss;
 	int res = 0, i;
 
-	if (slave_dev->type == ARPHRD_CAN) {
+	if (slave_dev->type == ARPHRD_CAN ||
+	    slave_dev->type == ARPHRD_IEEE802154 ||
+	    slave_dev->type == ARPHRD_IEEE802154_MONITOR ||
+	    slave_dev->type == ARPHRD_6LOWPAN) {
 		BOND_NL_ERR(bond_dev, extack,
-			    "CAN devices cannot be enslaved");
+			    "CAN, IEEE 802.15.4 and 6LoWPAN devices cannot be enslaved");
 		return -EPERM;
 	}
 
-- 
2.53.0

Re: [PATCH] bonding: reject IEEE 802.15.4 and 6LoWPAN devices in bond_enslave

[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 LLM and not proven at runtime). If it was triggered
   please include the symptoms, like the stack trace or kernel 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] bonding: reject IEEE 802.15.4 and 6LoWPAN devices in bond_enslave

[KALPESH SOLANKI]

Hi,

To provide the requested context for reviewers:

1. Discovery:
The issue was identified via manual code inspection of bond_enslave()
following up on commit 9043be310c6a ("team: reject CAN, IEEE 802.15.4
and 6LoWPAN devices in team_port_add"). Commit 9043be310c6a noted that
bonding had only blocked CAN devices (commit 8ba68464e478), leaving
bonding exposed to the exact same IEEE 802.15.4 and 6LoWPAN type
inconsistencies.

2. Triggering / Symptoms:
The bug is triggerable at runtime by creating an IEEE 802.15.4 device
(e.g., via mac802154_hwsim or fakelb) or 6LoWPAN device, enslaving it
while down to a bonding master, and:
- For IEEE 802.15.4: issuing a netlink dump (e.g., IEEE802154_LLSEC_LIST_KEY),
  where ieee802154_llsec_dump_table() unconditionally dereferences
  dev->ieee802154_ptr / ieee802154_mlme_ops(dev) on the bond device,
  causing a NULL pointer dereference (as dev->ml_priv is NULL).
- For 6LoWPAN: on NETDEV_DOWN, lowpan_event() casts netdev_priv(dev) to
  struct lowpan_dev and writes to ctx.table, corrupting struct bonding.

Thanks,
Kalpesh

Re: [PATCH] bonding: reject IEEE 802.15.4 and 6LoWPAN devices in bond_enslave

[Oliver Hartkopp]

Hi Kalpesh,

many thanks for picking this up!

On 12.11.26 14:08, Kalpesh Solanki wrote:
> When the first non-Ethernet slave is enslaved to a bond,
> bond_setup_by_slave() copies slave_dev->type to the bond device.
> However, the bonding driver does not set up subsystem-specific
> mid-layer contexts or private structures:
> 
> 1. IEEE 802.15.4 routines (such as ieee802154_llsec_dump_table(),
>     nl-phy.c, and socket callbacks) identify WPAN devices by dev->type
>     alone and unconditionally dereference dev->ieee802154_ptr and
>     dev->ml_priv (ieee802154_mlme_ops). Because bonding never allocates
>     these, this results in a NULL pointer dereference.
> 
> 2. The 6LoWPAN netdevice notifier (lowpan_event()) identifies devices
>     by dev->type == ARPHRD_6LOWPAN and treats netdev_priv(dev) as
>     struct lowpan_dev. On a bond master, netdev_priv() is struct bonding,
>     so writes to lowpan_dev(dev)->ctx.table flags on events like
>     NETDEV_DOWN corrupt the bonding driver's private state.
> 
> The team driver closed an identical gap in commit 9043be310c6a ("team:
> reject CAN, IEEE 802.15.4 and 6LoWPAN devices in team_port_add"). Bonding
> previously only blocked CAN devices in commit 8ba68464e478 ("bonding:
> refuse to enslave CAN devices").

You could have referenced the bonding-splats from my patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9043be310c6a4c5e57f7bba4b9870554eac7aa96

So it is not only that this problem has been found by manual code 
inspection.

> Reject ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR, and ARPHRD_6LOWPAN
> devices in bond_enslave().
> 
> Fixes: 8ba68464e478 ("bonding: refuse to enslave CAN devices")
> Signed-off-by: Kalpesh Solanki <skalpesh942@gmail.com>

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

Best regards,
Oliver

> ---
>   drivers/net/bonding/bond_main.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 7019e5d8fdc..b3b003e39b2 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1894,9 +1894,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
>   	struct sockaddr_storage ss;
>   	int res = 0, i;
>   
> -	if (slave_dev->type == ARPHRD_CAN) {
> +	if (slave_dev->type == ARPHRD_CAN ||
> +	    slave_dev->type == ARPHRD_IEEE802154 ||
> +	    slave_dev->type == ARPHRD_IEEE802154_MONITOR ||
> +	    slave_dev->type == ARPHRD_6LOWPAN) {
>   		BOND_NL_ERR(bond_dev, extack,
> -			    "CAN devices cannot be enslaved");
> +			    "CAN, IEEE 802.15.4 and 6LoWPAN devices cannot be enslaved");
>   		return -EPERM;
>   	}
>