From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5FB54071DA; Sun, 7 Jun 2026 10:19:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780827600; cv=none; b=HfLqmh0vYTJ/81/f3NN2Oc4G7gtWcmv7obSHs5LfTBkAEW66ADsMUpwaF2zrwX1DQ2f1nubu9b8D+3+KoxWyTEUlqBiXraqvLq6aH2RsDdNBRkLBmxXTzMjfUZK++cEyOruOR1nWbF/NsmNnHqtx5D/ykZ32Bhx6D3swoi3Sx4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780827600; c=relaxed/simple; bh=vzoKuirsAhsvS7o6iyYsZ9HXYV5J/qJFDe6d40RmD48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aWCCt67KISAWwW/iLn2uhmA4+WDfsLhvCNJvCRSKH9Bho+MXnidPhXxee3uEwcW7oFxcRTXIo7nsF/yF4hC9J6jGuw8xc7sQ5uljVSMEwCVBtGTwghAq+5Amw3hJ1SVw8VGng57OFWCzLDCVDmOzQcMFGY0BjA5yX0J0KNILmzI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=c4CrEAzU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="c4CrEAzU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CEE81F00893; Sun, 7 Jun 2026 10:19:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1780827599; bh=n3j4iDJi9sDyJ8Xto0HPNYXhBvvYHsJOTFmpsbmoDMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=c4CrEAzUNZHtE2vQBIMC6y/alhUvXyTIKRs30rvcdcBhSf39cq3xWo/WUOf3m22s7 MleLDKRy45VJxVHlQTv8wqJtjNsux52pv/ZzWGkUmi//rWk7zaoVcc5K/zfUjMzWSh of4ONkFfzmc6wZvxS1DDdkLfXyEtuZfBWbAC1rwE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+8ed98cbd0161632bce95@syzkaller.appspotmail.com, Oliver Hartkopp , Jay Vosburgh , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.12 065/307] bonding: refuse to enslave CAN devices Date: Sun, 7 Jun 2026 11:57:42 +0200 Message-ID: <20260607095730.139796857@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260607095727.647295505@linuxfoundation.org> References: <20260607095727.647295505@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Oliver Hartkopp [ Upstream commit 8ba68464e4787b6a7ec938826e16124df20fd23d ] 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 Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260526-bonding-candev-v1-1-ba1df400918a@hartkopp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- 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 1b2cd7f870353c..c6b114946d9a5a 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -1927,6 +1927,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, int link_reporting; 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, -- 2.53.0