netdev - RE: KMSAN: uninit-value in strcmp

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CY4PR15MB157567D1E7FB74789CBAB6D99A860@CY4PR15MB1575.namprd15.prod.outlook.com>
Date:   Fri, 4 May 2018 01:58:46 +0000
From:   Jon Maloy <jon.maloy@...csson.com>
To:     David Miller <davem@...emloft.net>,
        "syzbot+df0257c92ffd4fcc58cd@...kaller.appspotmail.com" 
        <syzbot+df0257c92ffd4fcc58cd@...kaller.appspotmail.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        "tipc-discussion@...ts.sourceforge.net" 
        <tipc-discussion@...ts.sourceforge.net>,
        "ying.xue@...driver.com" <ying.xue@...driver.com>
Subject: RE: KMSAN: uninit-value in strcmp



> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Thursday, May 03, 2018 15:22
> To: syzbot+df0257c92ffd4fcc58cd@...kaller.appspotmail.com
> Cc: Jon Maloy <jon.maloy@...csson.com>; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org; syzkaller-bugs@...glegroups.com; tipc-
> discussion@...ts.sourceforge.net; ying.xue@...driver.com
> Subject: Re: KMSAN: uninit-value in strcmp
> 
> From: syzbot <syzbot+df0257c92ffd4fcc58cd@...kaller.appspotmail.com>
> Date: Thu, 03 May 2018 11:44:02 -0700
> 
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:17 [inline]
> >  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
> >  kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> >  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> >  strcmp+0xf7/0x160 lib/string.c:329
> >  tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881
> > genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
> 
> Hmmm, TIPC_NL_LINK_GET uses tipc_nl_policy, which has a proper nesting
> entry for TIPC_NLA_LINK.  I wonder how the code goes about validating
> TIPC_NLA_LINK_NAME in such a case?  Does it?

I assume that a strncmp() instead of a strcmp() would avert this particular crash, but it doesn't sound like that is what you are after here?
To be honest, I will need to study this code a little myself to understand if there is more that has to be done.

///jon

> 
> This may be the problem.