blob: 7221d8c8dac92019944485fa5fe15e441ed940bd [file] [log] [blame]
From 7d4c6d5f5887e3978a6c80a332789c6c0300aed1 Mon Sep 17 00:00:00 2001
From: David Ahern <>
Date: Fri, 10 Jan 2020 09:03:58 -0800
Subject: [PATCH] ipv4: Detect rollover in specific fib table dump
commit 9827c0634e461703abf81e8cc8b7adf5da5886d0 upstream.
Sven-Haegar reported looping on fib dumps when 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 <>
Signed-off-by: David Ahern <>
Signed-off-by: David S. Miller <>
Signed-off-by: Paul Gortmaker <>
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 868c74771fa9..e6261756057f 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2067,6 +2067,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;