From: Vladis Dronov <vdronov@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller-bugs@googlegroups.com
Subject: Re: KMSAN: uninit-value in __dev_mc_add
Date: Thu, 27 Sep 2018 19:10:13 -0400 (EDT) [thread overview]
Message-ID: <525568947.16793847.1538089813920.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CANn89iJNNfiEPM24NgnodV-QUnCyJcrRjKsHV9jdP4i3fBdESw@mail.gmail.com>
Hello, Eric, all,
> I dunno, your patch looks quite not the right fix.
I agree, it looks more like a dirty hack. Unfortunately, I lack the deep
expertise in the network stack subsystem, so I've posted the patch to,
sort of, start a discussion and probably get some hints.
> If TUN is able to change dev->type, how comes it does not set the
> appropriate dev->addr_len at the same time ?
Well,... probably, nobody cared to do so:
[drivers/net/tun.c]
case TUNSETLINK:
...
tun->dev->type = (int) arg; //<--- that's all!
tun_debug(KERN_INFO, tun, "linktype set to %d\n",
tun->dev->type);
ret = 0;
}
break;
> Really the bug seems to be deeper, and without setting proper
> dev->addr_len, we'll need more 'fixes' like yours.
Absolutely. Unfortunately, I wasn't able to just write such deeper patch.
Let me share what I have found and let me hope to get an advise.
- So setting just the tun->dev->type makes the dev struct inconsistent.
- There are more field to adjust, at least dev->broadcast. Also, there are
a number of *_ops fields which are all set for the Ethernet type, most
probably they must be adjusted also.
- There is no get_addr_len_by_link_type() or a simple way to get link layer
properties by dev->type. Such settings are scattered in *_setup and
*_init functions, like ipgre_tunnel_init() { ... dev->addr_len = 4; ...}
Having these, I can imagine 2 ways for a proper fix.
1) Destroy the net_device in question and recreate it when changing a link
type. This way all the dev fields are set right. Create it in a similar way
as rtnl_newlink() does. Again, we do not have get_X_by_link_type(), so it
probably will be some large switch()/case:
$ grep '^#define ARPHRD_' include/uapi/linux/if_arp.h | wc -l
59
2) Leave tun an Ethernet device, add some tun->pretend_to_be_this_link_type
field and change only it on TUNSETLINK. And use this field in cases for which
TUNSETLINK was invented in the first place. Unfortunately, I do not have such
a list. The initial the commit ff4cc3ac93e1 says:
For use with
wireless and other networking types it should be possible to set the
ARP type via an ioctl.
Surely, there can be something else which I do not see. Could anyone suggest
an advice on this?
Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer
next prev parent reply other threads:[~2018-09-27 23:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 14:24 KMSAN: uninit-value in __dev_mc_add syzbot
2018-09-27 21:30 ` Vladis Dronov
2018-09-27 22:22 ` Eric Dumazet
2018-09-27 23:10 ` Vladis Dronov [this message]
2018-10-08 13:06 ` 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=525568947.16793847.1538089813920.JavaMail.zimbra@redhat.com \
--to=vdronov@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzbot+001516d86dbe88862cec@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.