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
prev parent 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