linux-kernel - Re: [net-next PATCH] ipv6: fix false-postive maybe-uninitialized warning

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: <20170818.104940.305624900632112023.davem@davemloft.net>
Date:   Fri, 18 Aug 2017 10:49:40 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     arnd@...db.de
Cc:     kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org, fw@...len.de,
        dsahern@...il.com, kafai@...com, weiwan@...gle.com,
        xiyou.wangcong@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH] ipv6: fix false-postive maybe-uninitialized
 warning

From: Arnd Bergmann <arnd@...db.de>
Date: Fri, 18 Aug 2017 13:34:22 +0200

> Adding a lock around one of the assignments prevents gcc from
> tracking the state of the local 'fibmatch' variable, so it can no
> longer prove that 'dst' is always initialized, leading to a bogus
> warning:
> 
> net/ipv6/route.c: In function 'inet6_rtm_getroute':
> net/ipv6/route.c:3659:2: error: 'dst' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This moves the other assignment into the same lock to shut up the
> warning.
> 
> Fixes: 121622dba8da ("ipv6: route: make rtm_getroute not assume rtnl is locked")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
>  net/ipv6/route.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> This kind of warning involving an unlock between variable initialization
> and use is relatively frequent for false-positives. I should try to
> seek clarification from the gcc developers on whether this can be
> improved.

This will have to do for now I suppose.

I guess the issue is that if the local variable ever sits on the stack
then the memory barriers in the locks block the full dataflow
analysis.

But this makes no sense from a dataflow perspective.  Even if the
local variable has a stack slot, there is no "escapability" of that
memory addres to foreign modifications.

If I had a nickel for every uninitialized variable warning we had to
work around....