| Message ID | 20181208231104.18067-1-fw@strlen.de |
|---|---|
| State | Changes Requested |
| Delegated to: | Pablo Neira |
| Headers | show |
| Series | [nf,v2] netfilter: nat: limit port clash resolution attempts | expand |
Hi Florian, On Sun, Dec 09, 2018 at 12:11:04AM +0100, Florian Westphal wrote: > In case almost or all available ports are taken, clash resolution can > take a very long time, resulting in soft lockup. > > This can happen when many to-be-natted hosts connect to same > destination:port (e.g. a proxy) and all connections pass the same SNAT. > > Pick a random offset in the acceptable range, then try ever smaller > number of adjacent port numbers, until either the limit is reached or a > useable port was found. This results in at most 248 attempts > (128 + 64 + 32 + 16 + 8, i.e. 4 restarts with new search offset) > instead of 64000+, > > v2: increment 'i' too in for loop (Xiaozhou Liu) > > Signed-off-by: Florian Westphal <fw@strlen.de> > --- > Pablo, > > this will unfortunately result in a nf-next merge conflict > due to *rover removal in nf-next. > I can send a patch vs. nf-next instead if you prefer. If you let me choose, I would prefer we route this through nf-next. Thanks!
diff --git a/net/netfilter/nf_nat_proto_common.c b/net/netfilter/nf_nat_proto_common.c index 5d849d835561..0e3321660624 100644 --- a/net/netfilter/nf_nat_proto_common.c +++ b/net/netfilter/nf_nat_proto_common.c @@ -41,9 +41,10 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto *l3proto, const struct nf_conn *ct, u16 *rover) { - unsigned int range_size, min, max, i; + unsigned int range_size, min, max, i, attempts; __be16 *portptr; - u_int16_t off; + u16 off; + static const unsigned int max_attempts = 128; if (maniptype == NF_NAT_MANIP_SRC) portptr = &tuple->src.u.all; @@ -89,15 +90,32 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto *l3proto, off = *rover; } - for (i = 0; ; ++off) { + attempts = range_size; + if (attempts > max_attempts) + attempts = max_attempts; + + /* We are in softirq; doing a search of the entire range risks + * soft lockup when all tuples are already used. + * + * If we can't find any free port from first offset, pick a new + * one and try again, with ever smaller search window. + */ +another_round: + for (i = 0; i < attempts; i++, off++) { *portptr = htons(min + off % range_size); - if (++i != range_size && nf_nat_used_tuple(tuple, ct)) + if (nf_nat_used_tuple(tuple, ct)) continue; if (!(range->flags & (NF_NAT_RANGE_PROTO_RANDOM_ALL| NF_NAT_RANGE_PROTO_OFFSET))) *rover = off; return; } + + if (attempts >= range_size || attempts < 16) + return; + attempts /= 2; + off = prandom_u32(); + goto another_round; } EXPORT_SYMBOL_GPL(nf_nat_l4proto_unique_tuple);
In case almost or all available ports are taken, clash resolution can take a very long time, resulting in soft lockup. This can happen when many to-be-natted hosts connect to same destination:port (e.g. a proxy) and all connections pass the same SNAT. Pick a random offset in the acceptable range, then try ever smaller number of adjacent port numbers, until either the limit is reached or a useable port was found. This results in at most 248 attempts (128 + 64 + 32 + 16 + 8, i.e. 4 restarts with new search offset) instead of 64000+, v2: increment 'i' too in for loop (Xiaozhou Liu) Signed-off-by: Florian Westphal <fw@strlen.de> --- Pablo, this will unfortunately result in a nf-next merge conflict due to *rover removal in nf-next. I can send a patch vs. nf-next instead if you prefer. net/netfilter/nf_nat_proto_common.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-)