netdev - route: an issue caused by local and main table's merge

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 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]

Date:   Mon, 2 Mar 2020 16:38:59 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     network dev <netdev@...r.kernel.org>,
        David Ahern <dsahern@...il.com>, davem <davem@...emloft.net>,
        mmhatre@...hat.com
Subject: route: an issue caused by local and main table's merge

Hi, David A.

Mithil reported an issue, which can be reproduced by:

  # ip link  add dummy0 type dummy
  # ip link  set dummy0 up
  # ip route add to broadcast 192.168.122.1 dev dummy0 <--- broadcast
  # ip route add 192.168.122.1 dev dummy0   <--- unicast
  # ip route add 1.1.1.1 via 192.168.122.1  <--- [A]
  Error: Nexthop has invalid gateway.
  # ip rule  add from 2.2.2.2
  # ip route add 1.1.1.1 via 192.168.122.1  <--- [B]

cmd [A] failed , as in fib_check_nh_v4_gw():

    if (table)
            tbl = fib_get_table(net, table);

    if (tbl)
            err = fib_table_lookup_2(tbl, &fl4, &res,
                                   FIB_LOOKUP_IGNORE_LINKSTATE |
                                   FIB_LOOKUP_NOREF);

    if (res.type != RTN_UNICAST && res.type != RTN_LOCAL) { <--- [a]
            NL_SET_ERR_MSG(extack, "Nexthop has invalid gateway");
            goto out;  <--[a]
    }

It gets the route for '192.168.122.1' from the merged (main/local)
table, and the broadcast one returns, and it fails the check [a].

But the same cmd [B] will work after one rule is added, by which
main table and local table get separated, it gets the route from
the main table (the same table for this route), and the unicast
one returns, and it will pass the check [a].

Any idea on how to fix this, and keep it consistent before and
after a rule added?

Thanks.