netdev - Re: [PATCH net-next] ipv4/fib: send RTM

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]

Date: Mon, 24 Jul 2023 16:56:37 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Ido Schimmel <idosch@...sch.org>
Cc: David Ahern <dsahern@...nel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Thomas Haller <thaller@...hat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush
 fib

On Sun, Jul 23, 2023 at 10:38:11AM +0300, Ido Schimmel wrote:
> > > >>> @@ -2088,6 +2089,11 @@ int fib_table_flush(struct net *net, struct fib_table *tb, bool flush_all)
> > > >>>
> > > >>>                         fib_notify_alias_delete(net, n->key, &n->leaf, fa,
> > > >>>                                                 NULL);
> > > >>> +                       if (!(fi->fib_flags & RTNH_F_LINKDOWN)) {
> > > >>> +                               rtmsg_fib(RTM_DELROUTE, htonl(n->key), fa,
> > > >>> +                                         KEYLENGTH - fa->fa_slen, tb->tb_id, &info, 0);
> > > >>> +                       }
> > > >>
> > > >> Will you get a notification in this case for 198.51.100.0/24?
> > > > 
> > > > No. Do you think it is expected with this patch or not?
> > > 
> > > The intent is that notifications are sent for link events but not route
> > > events which are easily deduced from the link events.
> > 
> > Sorry, I didn't get what you mean. The link events should be notified to user
> > via rtmsg_ifinfo_event()? So I think here we ignore the route events caused by
> > link down looks reasonable.
> 
> The route in the scenario I mentioned wasn't deleted because of a link
> event, but because the source address was deleted yet no notification
> was emitted. IMO, this is wrong given the description of the patch.

OK. I got what you mean now. Is there a way to get the device the route
bond in fib_table_flush() so we can also check the dev flag?

> 
> I assume NetworkManager already knows how to delete routes given
> RTM_DELLINK events. Can't it be taught to react to RTM_DELADDR events as
> well? Then this functionality will always work, regardless of the kernel
> version being used.

The NetworkManager keeps a cache of the routes. Missing/Wrong events mean that
the cache becomes inconsistent. The IPv4 will not send src route delete info
if it's bond to other device. While IPv6 only modify the src route instead of
delete it, and also no notify. So NetworkManager developers complained and
hope to have a consistent and clear notification about route modify/delete.

Thanks
Hangbin