netdev - Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario

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: <alpine.LNX.2.01.1103150210370.21929@obet.zrqbmnf.qr>
Date:	Tue, 15 Mar 2011 02:16:45 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Changli Gao <xiaosuo@...il.com>
cc:	Patrick McHardy <kaber@...sh.net>,
	"David S. Miller" <davem@...emloft.net>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT
 scenario


On Tuesday 2011-03-15 00:49, Changli Gao wrote:
>>>the final tuples will be:
>>>src = home dst = router src=1.2.3.4 dst=192.168.0.1
>>>
>>>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
>>>conn will be removed later as there isn't any conntrack, which has
>>>this tuple in any direction.
>>
>> But I don't yet see how your patch #1 can help. At the time
>> conn->tuple = *tuple is done, *tuple still contains the non-SNATed
>> tuple, and it is never updated again.
>
>In this patch, conn->addr is used to save the destination/source
>address instead of conn->tuple.src.u3, so the conn->tuple is used for
>conntrack lookup only. Just as the original tuple isn't updated, we
>can use it to looking up the associated conntrack all the time.

The original tuple may not be updated, but the reply tuple is.
And we are taking the reply tuple in

	tuple_ptr = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;

which is subsequently copied to conn->tuple on the first invocation.

Afterwards, SNAT will update ct->tuplehash[reply].tuple, and so
conn->tuple is outdated. Calling nf_conntrack_find_get(conn->tuple)
in count_them would then fail, would it not?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html