linux-kernel - Re: [PATCH] [net-next] net: sched: avoid uninitialized variable use

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: <CAK8P3a1KZiiVY-BF8QMHHUAUzHEJsB_FCMGWdSOsQUku7D7QNw@mail.gmail.com>
Date:   Thu, 18 Jan 2018 15:19:14 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        David Ahern <dsa@...ulusnetworks.com>,
        Networking <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [net-next] net: sched: avoid uninitialized variable use

On Thu, Jan 18, 2018 at 2:49 PM, Jiri Pirko <jiri@...nulli.us> wrote:
> Thu, Jan 18, 2018 at 02:17:28PM CET, arnd@...db.de wrote:
>>gcc has identified a code path in which we pass uninitialized
>>data into tc_dump_tfilter():
>>
>>net/sched/cls_api.c: In function 'tc_dump_tfilter':
>>net/sched/cls_api.c:1268:8: error: 'parent' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>>This initializes the variable to the value it had before the previous
>>change.
>>
>>Fixes: 7960d1daf278 ("net: sched: use block index as a handle instead of qdisc when block is shared")
>>Signed-off-by: Arnd Bergmann <arnd@...db.de>
>>----
>>I don't know if my patch is the best way to address the issue, but
>>if not, then at least it helps show what the warning is about
>>and lets someone else come up with a better solution.
>
> I already sent a fix for this:
> http://patchwork.ozlabs.org/patch/862787/

Ok. I've looked at your patch for way too long now and still don't see how
you've shown it to be correct. Shouldn't there be a at least a comment
to explain why zero is an appropriate initialization value in that case?

      Arnd