[PATCH net 0/2] inetpeer: harden tree sizing and address side-channel eviction
From: Eric Dumazet <edumazet@google.com>
Date: 2026-08-12 20:59:50
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 <redacted> 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