linux-kernel - [patch] ip_local_port_range sysctl has annoying default

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-next>] [day] [month] [year] [list]

Date:	Fri, 11 May 2007 17:01:35 -0700
From:	Mark Glines <mark@...nes.org>
To:	linux-kernel@...r.kernel.org
Subject: [patch] ip_local_port_range sysctl has annoying default

On a powerpc machine (kurobox) I have here with 128M of RAM, the default
value of /proc/sys/net/ipv4/ip_local_port_range is:
2048    4999

This setting affects the port assigned to an application by default
when the application doesn't specify a port to use, like, for instance,
an outgoing connection.  It affects both TCP and UDP.  The default
values for this sysctl vary depending on the size of the tcp bind hash,
which in turn, varies depending on the size of the system RAM (I think).

By a one-in-a-million coincidence, this machine has a default port
range starting with 2048, and this breaks things for me.  I'm trying to
run both klive and nfs on this box, but klive starts first (probably
because of the filename sort order), and claims UDP port 2049 for its
own purposes, causing the nfs server to fail to start.

If the bind hash size is over a certain threshold, the range
32768-61000 is used.  If it is under a certain threshold, a range
like (1024|2048|3072)-4999 is used, depending on exactly how small it
is.  Thix box happened to get the 2048-4999 range, which broke nfs.

A comment just above the code that does this says, "Try to be a bit
smarter and adjust defaults depending on available memory."  "smarter"?
Maybe, maybe not.  Either way, it's unexpected.

Following the principle of least astonishment, I think it seems better
to use high, out-of-the-way port numbers regardless of how much RAM the
system has.  So, the following patch changes this behavior slightly.
The system still picks a dynamic range depending on the bind hash size,
but now, all ranges start with 32768.  I suppose another reasonable way
to do this would be to end all ranges with 61000, or something like
that.

It also seems funny to me that this would be in tcp_init(), when it
affects both TCP and UDP.  But hey, it is where it is.

Signed-off-by: Mark Glines <mark@...nes.org>

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bd4c295..4431b87 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2464,14 +2464,14 @@ void __init tcp_init(void)
 			(tcp_hashinfo.bhash_size * sizeof(struct inet_bind_hashbucket));
 			order++)
 		;
+	sysctl_local_port_range[0] = 32768;
 	if (order >= 4) {
-		sysctl_local_port_range[0] = 32768;
 		sysctl_local_port_range[1] = 61000;
 		tcp_death_row.sysctl_max_tw_buckets = 180000;
 		sysctl_tcp_max_orphans = 4096 << (order - 4);
 		sysctl_max_syn_backlog = 1024;
 	} else if (order < 3) {
-		sysctl_local_port_range[0] = 1024 * (3 - order);
+		sysctl_local_port_range[1] = 32768 + (1024 * order);
 		tcp_death_row.sysctl_max_tw_buckets >>= (3 - order);
 		sysctl_tcp_max_orphans >>= (3 - order);
 		sysctl_max_syn_backlog = 128;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/