All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	syzbot <syzbot+b02ff0707a97e4e79ebb@syzkaller.appspotmail.com>,
	davem@davemloft.net, glider@google.com,
	linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: KMSAN: uninit-value in can_receive
Date: Wed, 20 Nov 2019 21:10:24 +0100	[thread overview]
Message-ID: <c1f80bac-bb75-e671-ba32-05cfae86569c@hartkopp.net> (raw)
In-Reply-To: <92c04159-b83a-3e33-91da-25a727a692d0@gmail.com>

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

  reply	other threads:[~2019-11-20 20:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 19:05 KMSAN: uninit-value in can_receive syzbot
2019-11-18 20:25 ` Oliver Hartkopp
2019-11-18 20:29   ` Marc Kleine-Budde
2019-11-18 20:49     ` Oliver Hartkopp
2019-11-18 21:15       ` Marc Kleine-Budde
2019-11-19  7:35         ` Oliver Hartkopp
2019-11-19  9:00           ` Oleksij Rempel
2019-11-19 10:08           ` Dmitry Vyukov
2019-11-19 13:06             ` Alexander Potapenko
2019-11-19 16:53           ` Eric Dumazet
2019-11-19 20:24             ` Oliver Hartkopp
2019-11-19 21:09               ` Eric Dumazet
2019-11-20 20:10                 ` Oliver Hartkopp [this message]
2019-12-03 10:09                   ` Marc Kleine-Budde
2019-12-03 10:37                     ` Oliver Hartkopp
2019-12-03 10:40                       ` Marc Kleine-Budde
2019-11-26  9:00 ` syzbot

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=c1f80bac-bb75-e671-ba32-05cfae86569c@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=glider@google.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+b02ff0707a97e4e79ebb@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.