Netdev List
 help / color / mirror / Atom feed
From: Jay Vosburgh <jv@jvosburgh.net>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-can@vger.kernel.org,
	syzbot+8ed98cbd0161632bce95@syzkaller.appspotmail.com
Subject: Re: [PATCH] bonding: refuse to enslave CAN devices
Date: Tue, 26 May 2026 18:36:24 -0700	[thread overview]
Message-ID: <387285.1779845784@famine> (raw)
In-Reply-To: <20260526-bonding-candev-v1-1-ba1df400918a@hartkopp.net>

Oliver Hartkopp <socketcan@hartkopp.net> wrote:

>syzbot reported a kernel paging request crash in
>can_rx_unregister() inside net/can/af_can.c. The crash occurs
>because a virtual CAN device (vxcan) is being enslaved to a
>bonding master.
>
>During the enslavement process, the bonding driver mutates
>and modifies the network device states to fit an Ethernet-like
>aggregation model. However, CAN devices operate on a completely
>different Layer 2 architecture, relying on the CAN mid-layer
>private data structure (can_ml_priv) instead of standard
>Ethernet structures. Since bonding does not initialize or
>maintain these CAN structures, subsequent operations on the
>half-enslaved interface (such as closing associated sockets
>via isotp_release) lead to a null-pointer dereference when
>accessing the CAN receiver lists.
>
>Bonding CAN interfaces is architecturally invalid as CAN lacks
>MAC addresses, ARP capabilities, and standard Ethernet
>link-layer mechanisms. While generic loopback devices are
>blocked globally in net/core/dev.c, virtual CAN devices
>bypass this check because they do not carry the IFF_LOOPBACK
>flag, despite acting as local software-loopbacks.
>
>Fix this by explicitly blocking network devices of type
>ARPHRD_CAN from being enslaved at the very beginning of
>bond_enslave(). This prevents illegal state mutations,
>eliminates the resulting KASAN crashes, and avoids potential
>memory leaks from incomplete socket cleanups.
>
>As the CAN support has been added a long time after bonding
>the Fixes-tag points to the introduction of ARPHRD_CAN that
>would have needed a specific handling in bonding_main.c.
>
>Fixes: cd05acfe65ed ("[CAN]: Allocate protocol numbers for PF_CAN")
>Reported-by: syzbot+8ed98cbd0161632bce95@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
>Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

Acked-by: Jay Vosburgh <jv@jvosburgh.net>

>---
> drivers/net/bonding/bond_main.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index af82a3df2c5d..82e779f7916b 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1888,10 +1888,16 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
> 	const struct net_device_ops *slave_ops = slave_dev->netdev_ops;
> 	struct slave *new_slave = NULL, *prev_slave;
> 	struct sockaddr_storage ss;
> 	int res = 0, i;
> 
>+	if (slave_dev->type == ARPHRD_CAN) {
>+		BOND_NL_ERR(bond_dev, extack,
>+			    "CAN devices cannot be enslaved");
>+		return -EPERM;
>+	}
>+
> 	if (slave_dev->flags & IFF_MASTER &&
> 	    !netif_is_bond_master(slave_dev)) {
> 		BOND_NL_ERR(bond_dev, extack,
> 			    "Device type (master device) cannot be enslaved");
> 		return -EPERM;
>
>---
>base-commit: d60ec36cab338dfe2ae40d73e9c8d6c4af70d2b8
>change-id: 20260526-bonding-candev-f4a0cf2eee9b
>
>Best regards,
>--  
>Oliver Hartkopp <socketcan@hartkopp.net>

---
	-Jay Vosburgh, jv@jvosburgh.net



      reply	other threads:[~2026-05-27  1:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 19:33 [PATCH] bonding: refuse to enslave CAN devices Oliver Hartkopp
2026-05-27  1:36 ` Jay Vosburgh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=387285.1779845784@famine \
    --to=jv@jvosburgh.net \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=socketcan@hartkopp.net \
    --cc=syzbot+8ed98cbd0161632bce95@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox