netdev - Re: [PATCH] bonding: do not enslave CAN devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <42aee2fd-b6d4-fa28-27fc-f8faab32c73f@hartkopp.net>
Date:   Sat, 21 Mar 2020 15:00:30 +0100
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        David Miller <davem@...emloft.net>,
        Sabrina Dubroca <sd@...asysnail.net>
Cc:     linux-can@...r.kernel.org, netdev@...r.kernel.org,
        syzbot+c3ea30e1e2485573f953@...kaller.appspotmail.com,
        dvyukov@...gle.com, j.vosburgh@...il.com, vfalico@...il.com,
        andy@...yhouse.net, stable@...r.kernel.org
Subject: Re: [PATCH] bonding: do not enslave CAN devices

+ 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:

>>> Like this:
>>>
>>> if (netdev->ops != &can_netdev_ops)
>>> 	return;
>>
>> 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.
> 
> ping,
> 
> are there any other ways or ideas how to solve this issue?

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