From: Eric Dumazet <edumazet@google.com>
To: Otto Hollmann <otto.hollmann@suse.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
David Ahern <dsahern@kernel.org>,
Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH net-next] net: document a side effect of ip_local_reserved_ports
Date: Thu, 1 Apr 2021 18:04:05 +0200 [thread overview]
Message-ID: <CANn89iJvtuT4q-djaCzoGJTY68vE8wT+LVDkYGm=8_XzC9gchg@mail.gmail.com> (raw)
In-Reply-To: <20210401155704.35341-1-otto.hollmann@suse.com>
On Thu, Apr 1, 2021 at 5:58 PM Otto Hollmann <otto.hollmann@suse.com> wrote:
>
> If there is overlapp between ip_local_port_range and ip_local_reserved_ports with a huge reserved block, it will affect probability of selecting ephemeral ports, see file net/ipv4/inet_hashtables.c:723
>
> int __inet_hash_connect(
> ...
> for (i = 0; i < remaining; i += 2, port += 2) {
> if (unlikely(port >= high))
> port -= remaining;
> if (inet_is_local_reserved_port(net, port))
> continue;
>
> E.g. if there is reserved block of 10000 ports, two ports right after this block will be 5000 more likely selected than others.
> If this was intended, we can/should add note into documentation as proposed in this commit, otherwise we should think about different solution. One option could be mapping table of continuous port ranges. Second option could be letting user to modify step (port+=2) in above loop, e.g. using new sysctl parameter.
>
> Signed-off-by: Otto Hollmann <otto.hollmann@suse.com>
I think we can view this as a security bug that needs a fix.
next prev parent reply other threads:[~2021-04-01 18:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 15:57 [PATCH net-next] net: document a side effect of ip_local_reserved_ports Otto Hollmann
2021-04-01 16:04 ` Eric Dumazet [this message]
2021-04-01 23:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANn89iJvtuT4q-djaCzoGJTY68vE8wT+LVDkYGm=8_XzC9gchg@mail.gmail.com' \
--to=edumazet@google.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=otto.hollmann@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).