From: Eric Dumazet <edumazet@google.com>
To: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>, Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
Eric Dumazet <edumazet@google.com>,
Michael Blunt <michaelbblunt@gmail.com>
Subject: [PATCH net 0/2] inetpeer: harden tree sizing and address side-channel eviction
Date: Wed, 12 Aug 2026 20:59:44 +0000 [thread overview]
Message-ID: <20260812205946.356185-1-edumazet@google.com> (raw)
This series addresses a vulnerability in the inetpeer subsystem where an
off-path adversary can manipulate garbage collection to bypass IP-keyed
ICMP rate limits, and hardens inetpeer memory usage under pressure.
The inetpeer rate limiting system stores peer entries in an RB-tree keyed
deterministically by remote IP address. Because tree lookups walk the
tree using lexicographical comparison (inetpeer_addr_cmp), an off-path
attacker can predict the tree topology and the exact sequence of nodes
traversed during lookups (the gc_stack candidate list). By combining
predictable traversal with aggressive garbage collection triggered when
the tree size exceeds inet_peer_threshold, an attacker can selectively
force the eviction of targeted inet_peer nodes. When an evicted node is
recreated on the next packet, its rate-limiting token bucket is reset to
full capacity, creating a side-channel to bypass ICMP rate limits and
probe for open UDP ports.
- Patch 1 enforces a hard limit on inet_peer allocations at 2x
inet_peer_threshold to prevent unbounded slab memory growth if GC
cannot free entries, and ensures inet_peer_xrlim_allow() fails closed
(returns false) if peer allocation fails and returns NULL.
- Patch 2 randomizes RB-tree node ordering using SipHash with a secret
boot-time key (inetpeer_hash_key), making tree layout and GC eviction
paths unpredictable to off-path attackers.
Reported-by: Michael Blunt <michaelbblunt@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Eric Dumazet (2):
inetpeer: enforce hard limit on tree size and fix NULL peer rate limit
inetpeer: randomize RB-tree node comparison using SipHash
include/net/inetpeer.h | 4 ++++
net/ipv4/inetpeer.c | 43 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 42 insertions(+), 5 deletions(-)
--
2.55.0.691.gc56d675ccc-goog
next reply other threads:[~2026-08-12 20:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 20:59 Eric Dumazet [this message]
2026-08-12 20:59 ` [PATCH net 1/2] inetpeer: enforce hard limit on tree size and fix NULL peer rate limit Eric Dumazet
2026-08-14 5:51 ` Eric Dumazet
2026-08-12 20:59 ` [PATCH net 2/2] inetpeer: randomize RB-tree node comparison using SipHash Eric Dumazet
2026-08-14 5:47 ` Eric Dumazet
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=20260812205946.356185-1-edumazet@google.com \
--to=edumazet@google.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=michaelbblunt@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.