netdev - Re: RTM_DELROUTE not sent anymore when deleting (last) nexthop of routes in 6.1

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: <CAOiHx=mKo_r-JTF0wtg3Aw+6-yvyorkm28GG1Dwp3viFg3x5NA@mail.gmail.com>
Date:   Thu, 24 Nov 2022 17:58:47 +0100
From:   Jonas Gorski <jonas.gorski@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>
Subject: Re: RTM_DELROUTE not sent anymore when deleting (last) nexthop of
 routes in 6.1

On Thu, 24 Nov 2022 at 17:04, Ido Schimmel <idosch@...sch.org> wrote:
>
> On Thu, Nov 24, 2022 at 04:20:49PM +0100, Jonas Gorski wrote:
> > We have an integration test using FRR that got broken by this, so I
> > can also easily test anything you throw at me (assuming CET working
> > hours).
>
> Please test the following fix [1]. Tested manually using [2]. With the
> fix or 61b91eb33a69 reverted the route is successfully deleted. Without
> the fix I get:
>
> RTNETLINK answers: No such process
> 198.51.100.0/24 nhid 1 via 192.0.2.2 dev dummy10
>
> If the fix is OK, I will submit it along with a selftest to make
> sure it does not regress in the future.
>
> Thanks
>
> [1]
> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
> index f721c308248b..19a662003eef 100644
> --- a/net/ipv4/fib_semantics.c
> +++ b/net/ipv4/fib_semantics.c
> @@ -888,9 +888,11 @@ int fib_nh_match(struct net *net, struct fib_config *cfg, struct fib_info *fi,
>                 return 1;
>         }
>
> -       /* cannot match on nexthop object attributes */
> -       if (fi->nh)
> -               return 1;
> +       if (fi->nh) {
> +               if (cfg->fc_oif || cfg->fc_gw_family || cfg->fc_mp)
> +                       return 1;
> +               return 0;
> +       }
>
>         if (cfg->fc_oif || cfg->fc_gw_family) {
>                 struct fib_nh *nh;

I can confirm this fixes the issue. Reading the code, this is
basically like it was before the commit with an additional return 1
for (fi->nh && cfg->fc_mp).

Thanks for the quick fix! Here, have a

Tested-by: Jonas Gorski <jonas.gorski@...il.com>

Regards
Jonas