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: <CADvbK_evghCnfNkePFkkLbaamXPaCOu-mSsSDKXuGSt65DSivw@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ