CVE-2026-90110: inetpeer: randomize RB-tree node comparison using SipHash

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

inetpeer: randomize RB-tree node comparison using SipHash

The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeeraddrcmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gcstack candidate list).

By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inetpeerthreshold), an attacker can selectively force the eviction of targeted inetpeer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (ratetokens, ratelast) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks).

Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeerhashkey) initialized via netgetrandomonce(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget.

Cache the computed 64-bit SipHash (hash) in struct inetpeer and compute the target hash (dhash) once at the beginning of inetgetpeer() to avoid recomputing SipHash at every step of the RB-tree walk.

Affected Software

1 affected component
Linux Kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Implement the kernel fix: randomize inet_peer Red-Black tree node comparison logic by ordering nodes using SipHash (SipHash(addr, inetpeer_hash_key)) rather than lexicographical IP comparisons (e.g., inetpeer_addr_cmp), and compute SipHash at each RB-tree walk step; use a secret SipHash key (inetpeer_hash_key) initialized via net_get_random_once() to make lookup/layout traversal paths unpredictable to off-path attackers.

    Linux kernel (inetpeer rate limiting; RB-tree lookup/insertion) RB-tree node comparison logic for inet_peer = Randomized using SipHash keyed with secret inetpeer_hash_key (initialized via net_get_random_once())

Event History

Sep 17, 2026
CVE Published
via MITRE·04:06 PM
Data Sourced
via MITRE·04:06 PM
Description

Frequently Asked Questions

1

What does an attacker need to exploit this issue?

The attack can be performed by an off-path adversary. It relies on predicting deterministic inetpeer Red-Black tree traversal and triggering aggressive garbage collection after the tree exceeds inet_peer_threshold.

2

What security controls can be bypassed or affected?

Evicting and then recreating a targeted inet_peer entry resets its rate-limiting token bucket to full capacity. This can bypass IP-keyed ICMP rate limits and provide a side channel for inferring open UDP ports.

3

What mitigation is described?

The resolved change randomizes inetpeer RB-tree node comparison with SipHash. It uses a secret inetpeer_hash_key initialized through net_get_random_once(), preventing predictable tree topology and traversal.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203