netdev - Re: 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 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: <1441d64c-c334-8c54-39e8-7a06a530089d@gmail.com>
Date:   Sun, 8 Mar 2020 20:29:56 -0600
From:   David Ahern <dsahern@...il.com>
To:     Xin Long <lucien.xin@...il.com>,
        network dev <netdev@...r.kernel.org>,
        davem <davem@...emloft.net>, mmhatre@...hat.com,
        "alexander.h.duyck@...el.com" <alexander.h.duyck@...el.com>
Subject: Re: route: an issue caused by local and main table's merge

[ This got lost in the backlog ]

On 3/2/20 1:38 AM, Xin Long wrote:
> 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?
> 

I do not have any suggestions off the top of my head.

Adding Alex who as I recall did the table merge.