[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJNNfiEPM24NgnodV-QUnCyJcrRjKsHV9jdP4i3fBdESw@mail.gmail.com>
Date: Thu, 27 Sep 2018 15:22:59 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: vdronov@...hat.com
Cc: syzbot+001516d86dbe88862cec@...kaller.appspotmail.com,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs@...glegroups.com
Subject: Re: KMSAN: uninit-value in __dev_mc_add
On Thu, Sep 27, 2018 at 2:30 PM Vladis Dronov <vdronov@...hat.com> wrote:
>
> Hello,
>
> This report is actually for the same bug which was reported in:
>
> https://syzkaller.appspot.com/bug?id=088efeac32fdde781038a777a63e436c0d4d7036
>
> The note there that the bug was fixed by "Commits: net: fix uninit-value in
> __hw_addr_add_ex()" is wrong. A C-reproducer from the 2nd syzkaller report
> can trigger the bug from this one.
>
> I've researched this and a result is a proposed patch, the problem is the tun
> device code allowing to set an arbitrary link type.
>
> https://lkml.org/lkml/2018/9/26/416
> https://lore.kernel.org/lkml/20180926093018.6646-1-vdronov@redhat.com/T/#u
> https://marc.info/?l=linux-netdev&m=153795423320016&w=2
>
I dunno, your patch looks quite not the right fix.
If TUN is able to change dev->type, how comes it does not set the
appropriate dev->addr_len at the same time ?
Really the bug seems to be deeper, and without setting proper
dev->addr_len, we'll need more 'fixes' like yours.
Thanks.
Powered by blists - more mailing lists