Since commit 8df9ffb888c ("can: make use of preallocated can_ml_priv for per device struct can_dev_rcv_lists") the device specific CAN receive filter lists are stored in netdev_priv() and dev->ml_priv points to these filters.
In the bug report Syzkaller enslaved a vxcan1 CAN device and accessed the bonding device with a PF_CAN socket which lead to a crash due to an access of an unhandled bond_dev->ml_priv pointer.
Deny to enslave CAN devices by the bonding driver as the resulting bond_dev pretends to be a CAN device by copying dev->type without really being one.
Reported-by: syzbot+c3ea30e1e2485573f953@syzkaller.appspotmail.com Fixes: 8df9ffb888c ("can: make use of preallocated can_ml_priv for per device struct can_dev_rcv_lists") Cc: linux-stable stable@vger.kernel.org # >= v5.4 Signed-off-by: Oliver Hartkopp socketcan@hartkopp.net --- drivers/net/bonding/bond_main.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 48d5ec770b94..4b781a7dfd96 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -1475,6 +1475,18 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, return -EPERM; }
+ /* CAN network devices hold device specific filter lists in + * netdev_priv() where dev->ml_priv sets a reference to. + * As bonding assumes to have some ethernet-like device it doesn't + * take care about these CAN specific filter lists today. + * So we deny the enslaving of CAN interfaces here. + */ + if (slave_dev->type == ARPHRD_CAN) { + NL_SET_ERR_MSG(extack, "CAN devices can not be enslaved"); + slave_err(bond_dev, slave_dev, "no bonding on CAN devices\n"); + return -EINVAL; + } + /* set bonding device ether type by slave - bonding netdevices are * created with ether_setup, so when the slave type is not ARPHRD_ETHER * there is a need to override some of the type dependent attribs/funcs.
Any updates, reviews, acks on this?
As pointed out by Sabrina here https://marc.info/?l=linux-netdev&m=158039302905460&w=2 the issue is also relevant for the TEAM driver.
Best, Oliver
On 30/01/2020 14.30, Oliver Hartkopp wrote:
On 1/30/20 2:30 PM, Oliver Hartkopp wrote:
Acked-by: Marc Kleine-Budde mkl@pengutronix.de
What's the preferred to upstream this? I could take this via the linux-can tree.
regards, Marc
From: Marc Kleine-Budde mkl@pengutronix.de Date: Tue, 25 Feb 2020 21:32:41 +0100
What I don't get is why the PF_CAN is blindly dereferencing a device assuming what is behind bond_dev->ml_priv.
If it assumes a device it access is CAN then it should check the device by comparing the netdev_ops or via some other means.
This restriction seems arbitrary.
On 27/02/2020 05.23, David Miller wrote:
Yes we do.
This restriction seems arbitrary.
Since commit 8df9ffb888c the data structures for the CAN filters have been moved from net/can/af_can.c into netdev->ml_priv.
PF_CAN only works with CAN interfaces and therefore always checks dev->type to be ARPHRD_CAN before accessing netdev->ml_priv.
Bonding and Team driver copy most of the device data structures to create bonding/team devices. They copy dev->type but *not* dev->ml_priv. That leads to the problematic ml_priv access after passing the dev->type check ...
I don't know yet whether it makes sense to have CAN bonding/team devices. But if so we would need some more investigation. For now disabling CAN interfaces for bonding/team devices seems to be reasonable.
Regards, Oliver
From: Oliver Hartkopp socketcan@hartkopp.net Date: Mon, 2 Mar 2020 09:45:41 +0100
Every single interesting device that falls into a special use case like CAN is going to be tempted to add a similar check.
I don't want to set this precedence.
Check that the devices you get passed are actually CAN devices, it's easy, just compare the netdev_ops and make sure they equal the CAN ones.
On 3/2/20 8:12 PM, David Miller wrote:
Sorry, I'm not really sure how to implement this check.
Should I maintain a list of all netdev_ops of all the CAN devices (= whitelist) and the compare against that list? Having a global list of pointers to network devices remind me of the old days of kernel-2.4.
regards, Marc
On Fri, Mar 6, 2020 at 3:12 PM Marc Kleine-Budde mkl@pengutronix.de wrote:
I think Dave means something like this:
$ grep "netdev_ops == " drivers/net/*/*.c net/*/*.c drivers/net/hyperv/netvsc_drv.c: if (event_dev->netdev_ops == &device_ops) drivers/net/ppp/ppp_generic.c: if (dev->netdev_ops == &ppp_netdev_ops) net/dsa/slave.c: return dev->netdev_ops == &dsa_slave_netdev_ops; net/openvswitch/vport-internal_dev.c: return netdev->netdev_ops == &internal_dev_netdev_ops;
From: Marc Kleine-Budde mkl@pengutronix.de Date: Fri, 6 Mar 2020 15:12:48 +0100
Like this:
if (netdev->ops != &can_netdev_ops) return;
Done.
On 3/7/20 6:13 AM, David Miller wrote:
There is no single can_netdev_ops. The netdev_ops are per CAN-network driver. But the ml_priv is used in the generic CAN code.
regards, Marc
On Mon, Mar 09, 2020 at 11:25:50AM +0100, Marc Kleine-Budde wrote:
ping,
are there any other ways or ideas how to solve this issue?
Regards, Oleksij
+ Sabrina Dubroca (takes care of team driver which has the same issue)
On 13/03/2020 10.56, Oleksij Rempel wrote:
On Mon, Mar 09, 2020 at 11:25:50AM +0100, Marc Kleine-Budde wrote:
On 3/7/20 6:13 AM, David Miller wrote:
Well, IMO the patch from https://marc.info/?l=linux-can&m=158039108004683 is still valid.
Although the attribution that commit 8df9ffb888c ("can: make use of preallocated can_ml_priv for per device struct can_dev_rcv_lists") introduced the problem could be removed.
Even before this commit dev->ml_priv of CAN interfaces has been used to store the filter lists. And either the bonding and the team driver do not take care of ml_priv.
They pretend to be CAN interfaces by faking dev->type to be ARPHRD_CAN - but they are not. When we dereference dev->ml_priv in (badly) faked CAN devices we run into the reported issue.
So the approach is to tell bonding and team driver to keep the fingers away from CAN interfaces like we do with some ARPHRD_INFINIBAND setups in bond_enslave() too.
Regards, Oliver
linux-stable-mirror@lists.linaro.org
-
David Miller -
Dmitry Vyukov -
Marc Kleine-Budde -
Oleksij Rempel -
Oliver Hartkopp -
Sabrina Dubroca