netdev - Re: ipmr, ip6mr: Unite dumproute flows

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

Message-ID: <c3d958d0-9916-48d9-ad8d-076cda75c93f@canonical.com>
Date:   Wed, 17 Oct 2018 19:22:16 +0100
From:   Colin Ian King <colin.king@...onical.com>
To:     Yuval Mintz <yuvalm@...lanox.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ipmr, ip6mr: Unite dumproute flows

Hi,

Static analysis on linux-next has picked up a potential bug with commit:

commit 7b0db85737db3f4d76b2a412e4f19eae59b8b494
Author: Yuval Mintz <yuvalm@...lanox.com>
Date:   Wed Feb 28 23:29:39 2018 +0200

    ipmr, ip6mr: Unite dumproute flows

in function mr_table_dump(), s_e is and never seems to change, so the
check if (e < s_e) is never true:  See code below, as annotated by
CoverityScan:

317        }
   assignment: Assigning: e = 0U.

318        e = 0;
   assignment: Assigning: s_e = 0U.

319        s_e = 0;
320
321        spin_lock_bh(lock);
322        list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
   at_least: At condition e < s_e, the value of e must be at least 0.
   const: At condition e < s_e, the value of s_e must be equal to 0.
   dead_error_condition: The condition e < s_e cannot be true.

323                if (e < s_e)

   CID 1474511 (#1 of 1): Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement: goto next_entry2;.

324                        goto next_entry2;
325                if (filter->dev &&
326                    !mr_mfc_uses_dev(mrt, mfc, filter->dev))
327                        goto next_entry2;
328
329                err = fill(mrt, skb, NETLINK_CB(cb->skb).portid,
330                           cb->nlh->nlmsg_seq, mfc, RTM_NEWROUTE, flags);
331                if (err < 0) {
332                        spin_unlock_bh(lock);
333                        goto out;
334                }
335next_entry2:

   incr: Incrementing e. The value of e is now 1.
   incr: Incrementing e. The value of e is now 2.

336                e++;

Note that the zero'ing of e and s_e for ipmr and ip6mr was added in by
earlier commits:

commit 8fb472c09b9df478a062eacc7841448e40fc3c17
Author: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Date:   Thu Jan 12 15:53:33 2017 +0100

    ipmr: improve hash scalability

commit 87c418bf1323d57140f4b448715f64de3fbb7e91
Author: Yuval Mintz <yuvalm@...lanox.com>
Date:   Wed Feb 28 23:29:31 2018 +0200

    ip6mr: Align hash implementation to ipmr

Anyhow, this looks incorrect, but I'm not familiar with this code to
suggest the correct fix.

Colin