CVE-2026-90110
CVE CVE-2026-90110EUVD EUVD-2026-81703Veröffentlicht 2026-09-17T16:06:18.000ZZuletzt geändert 2026-09-18T17:53:04.000ZCVSS 9.4
Was das Advisory beschreibt
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 (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) 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 (inetpeer_hash_key) initialized via net_get_random_once(). 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 inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk.
Quelle: EUVD (ENISA), im Wortlaut der Meldung.
Produkte, die das Advisory nennt
Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.
- Linux — Linux b145425f269a17ed344d737f746b844dfac60c82 <2ee66e9487172fcd189bc52a767c30dad7141c09; patch: 6.1.188; patch: 6.6.157; b145425f269a17ed344d737f746b844dfac60c82 <b20e98f0bb668a59abaf7bcf85d75c073e90d352; patch: 0; patch: 7.3-rc1; b145425f269a17ed344d737f746b844dfac60c82 <857681f6835d5b0a7bc4a34a026baeaaf5215623; b145425f269a17ed344d737f746b844dfac60c82 <7109bb63667a53e4542ad845476f97d0c8b28a61; patch: 6.18.52; b145425f269a17ed344d737f746b844dfac60c82 <5f127e3cc9647a8a70db12c65dbd0de473545380; 4.14; patch: 6.12.110; patch: 7.2.6; b145425f269a17ed344d737f746b844dfac60c82 <199fcf285e498111e029137d088949bc6c26d578
Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.
Im Produktkatalog geführt
Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.
- Linux — Linux
Betrifft das einen Ihrer Kundenbestände?
Diese Seite kann die Frage nicht beantworten — sie kennt Ihren Bestand nicht. Wer seine Umgebungen erfasst hat, bekommt die Antwort am Morgen nach der Veröffentlichung, zusammen mit einem Absatz, den er unverändert an den Kunden weitergeben kann.
28 Tage testenPatchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.