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

Date:   Thu, 18 Jan 2018 15:32:22 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Arnd Bergmann <arnd@...db.de>
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

Thu, Jan 18, 2018 at 03:19:14PM CET, arnd@...db.de wrote:
>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?

Okay. Will add comment.


>
>      Arnd