[PATCH] netfilter: xt_recent: don't reject rule if new hitcount exceeds table max

[PATCH] netfilter: xt_recent: don't reject rule if new hitcount exceeds table max

[Florian Westphal]

given:
-A INPUT -m recent --update --seconds 30 --hitcount 4
and
iptables-save > foo

then
iptables-restore < foo

will fail with:
kernel: xt_recent: hitcount (4) is larger than packets to be remembered (4) for table DEFAULT

Even when the check is fixed, the restore won't work if the hitcount is
increased to e.g. 6, since by the time checkentry runs it will find the
'old' incarnation of the table.

We can avoid this by increasing the maximum threshold silently; we only
have to rm all the current entries of the table (these entries would
not have enough room to handle the increased hitcount).

This even makes (not-very-useful)
-A INPUT -m recent --update --seconds 30 --hitcount 4
-A INPUT -m recent --update --seconds 30 --hitcount 42
work.

Fixes: abc86d0f99242b7f142b (netfilter: xt_recent: relax ip_pkt_list_tot restrictions)
Tracked-down-by: Chris Vine <chris@cvine.freeserve.co.uk>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
 net/netfilter/xt_recent.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 30dbe34..45e1b30 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -378,12 +378,11 @@ static int recent_mt_check(const struct xt_mtchk_param *par,
 	mutex_lock(&recent_mutex);
 	t = recent_table_lookup(recent_net, info->name);
 	if (t != NULL) {
-		if (info->hit_count > t->nstamps_max_mask) {
-			pr_info("hitcount (%u) is larger than packets to be remembered (%u) for table %s\n",
-				info->hit_count, t->nstamps_max_mask + 1,
-				info->name);
-			ret = -EINVAL;
-			goto out;
+		if (nstamp_mask > t->nstamps_max_mask) {
+			spin_lock_bh(&recent_lock);
+			recent_table_flush(t);
+			t->nstamps_max_mask = nstamp_mask;
+			spin_unlock_bh(&recent_lock);
 		}
 
 		t->refcnt++;
-- 
2.0.5

Re: [PATCH] netfilter: xt_recent: don't reject rule if new hitcount exceeds table max

[Pablo Neira Ayuso]

On Fri, Feb 13, 2015 at 12:47:50PM +0100, Florian Westphal wrote:
> given:
> -A INPUT -m recent --update --seconds 30 --hitcount 4
> and
> iptables-save > foo
> 
> then
> iptables-restore < foo
> 
> will fail with:
> kernel: xt_recent: hitcount (4) is larger than packets to be remembered (4) for table DEFAULT
> 
> Even when the check is fixed, the restore won't work if the hitcount is
> increased to e.g. 6, since by the time checkentry runs it will find the
> 'old' incarnation of the table.
> 
> We can avoid this by increasing the maximum threshold silently; we only
> have to rm all the current entries of the table (these entries would
> not have enough room to handle the increased hitcount).
> 
> This even makes (not-very-useful)
> -A INPUT -m recent --update --seconds 30 --hitcount 4
> -A INPUT -m recent --update --seconds 30 --hitcount 42
> work.

Applied, thanks Florian.