[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1f80bac-bb75-e671-ba32-05cfae86569c@hartkopp.net>
Date: Wed, 20 Nov 2019 21:10:24 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Eric Dumazet <eric.dumazet@...il.com>,
Marc Kleine-Budde <mkl@...gutronix.de>,
syzbot <syzbot+b02ff0707a97e4e79ebb@...kaller.appspotmail.com>,
davem@...emloft.net, glider@...gle.com, linux-can@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: KMSAN: uninit-value in can_receive
On 19/11/2019 22.09, Eric Dumazet wrote:
> On 11/19/19 12:24 PM, Oliver Hartkopp wrote:
>> Please check commit d3b58c47d330d ("can: replace timestamp as unique skb attribute").
>
> Oh well... This notion of 'unique skb attribute' is interesting...
Yes. The problem is that the joined filter needs to detect the identical
skb which is delivered several times to raw_rcv() to process filters
that are logical ANDed.
>> can_skb_prv(skb)->skbcnt is set to 0 at skb creation time when sending CAN frames from local host or receiving CAN frames from a real CAN interface.
>
> We can not enforce this to happen with a virtual interface.
You are right. I just discovered that I'm not able to send CAN frames
via PF_PACKET sockets anymore.
Receiving with a simple test program and Wireshark is fine - but sending
does not work. PF_PACKET is not creating the same kind of skbs as e.g.
the CAN_RAW socket does.
So the KMSAN detection was right at the end :-(
I'll take a closer look to enable PF_PACKET to send CAN frames again
which will fix up the entire problem.
Thanks for your feedback!
Best,
Oliver
Powered by blists - more mailing lists