* [PATCH net] ipv4: Detect rollover in specific fib table dump
@ 2020-01-10 17:03 David Ahern
2020-01-10 19:37 ` David Miller
0 siblings, 1 reply; 2+ messages in thread
From: David Ahern @ 2020-01-10 17:03 UTC (permalink / raw)
To: davem, jakub.kicinski; +Cc: netdev, haegar, David Ahern
From: David Ahern <dsahern@gmail.com>
Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has
been added to a table. The looping is caused by the key rolling over from
FFFFFFFF to 0. When dumping a specific table only, we need a means to detect
when the table dump is done. The key and count saved to cb args are both 0
only at the start of the table dump. If key is 0 and count > 0, then we are
in the rollover case. Detect and return to avoid looping.
This only affects dumps of a specific table; for dumps of all tables
(the case prior to the change in the Fixes tag) inet_dump_fib moved
the entry counter to the next table and reset the cb args used by
fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back
to 0 did not cause looping with the dumps.
Fixes: effe67926624 ("net: Enable kernel side filtering of route dumps")
Reported-by: Sven-Haegar Koch <haegar@sdinet.de>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/fib_trie.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index b9df9c09b84e..195469a13371 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2193,6 +2193,12 @@ int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
int count = cb->args[2];
t_key key = cb->args[3];
+ /* First time here, count and key are both always 0. Count > 0
+ * and key == 0 means the dump has wrapped around and we are done.
+ */
+ if (count && !key)
+ return skb->len;
+
while ((l = leaf_walk_rcu(&tp, key)) != NULL) {
int err;
--
2.11.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH net] ipv4: Detect rollover in specific fib table dump
2020-01-10 17:03 [PATCH net] ipv4: Detect rollover in specific fib table dump David Ahern
@ 2020-01-10 19:37 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2020-01-10 19:37 UTC (permalink / raw)
To: dsahern; +Cc: jakub.kicinski, netdev, haegar, dsahern
From: David Ahern <dsahern@kernel.org>
Date: Fri, 10 Jan 2020 09:03:58 -0800
> From: David Ahern <dsahern@gmail.com>
>
> Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has
> been added to a table. The looping is caused by the key rolling over from
> FFFFFFFF to 0. When dumping a specific table only, we need a means to detect
> when the table dump is done. The key and count saved to cb args are both 0
> only at the start of the table dump. If key is 0 and count > 0, then we are
> in the rollover case. Detect and return to avoid looping.
>
> This only affects dumps of a specific table; for dumps of all tables
> (the case prior to the change in the Fixes tag) inet_dump_fib moved
> the entry counter to the next table and reset the cb args used by
> fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back
> to 0 did not cause looping with the dumps.
>
> Fixes: effe67926624 ("net: Enable kernel side filtering of route dumps")
> Reported-by: Sven-Haegar Koch <haegar@sdinet.de>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, and queued up for -stable, thanks.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-01-10 19:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-10 17:03 [PATCH net] ipv4: Detect rollover in specific fib table dump David Ahern
2020-01-10 19:37 ` David Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.