CVE-2026-98234 in Linux
Zusammenfassung
von VulDB • 06.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/sched: hhf: Begrenzung von hh_flows_limit zum Änderungszeitpunkt
hhf_change() speichert TCA_HHF_HH_FLOWS_LIMIT ohne Obergrenze. Ein extrem hoher Wert für hh_flows_limit lässt jeden neuen „Heavy-Hitter“-Flow die Prüfung in alloc_new_hh() an hh_flows_current_cnt vorbeigehen und erzwingt eine kzalloc(GFP_ATOMIC)-Allokation fester Größe pro Flow bei gespooftem Traffic, was zu einem unbegrenzten Speicherwachstum führt.
Das Attribut wird mit NLA_POLICY_MAX() auf 2*HH_FLOWS_CNT (dem Standardwert von hhf_init()) begrenzt und der abgelehnte Wert wird über extack gemeldet. Die veraltete verschachtelte Parse-Logik bleibt erhalten: Legacy-tc setzt kein NLA_F_NESTED bei TCA_OPTIONS. Konfigurationen, die sich auf einen hh_limit oberhalb des Standardwerts stützten, beruhten auf einem unbegrenzten und unsicheren Verhalten und werden ab sofort nicht mehr unterstützt.
hhf_init() führte zuvor hhf_change() aus, bevor der Standardwert für hh_flows_limit festgelegt wurde; daher wurde ein vom Benutzer angegebener hh_limit zum Hinzufügenszeitpunkt wieder auf 2048 überschrieben. Der Standardwert wird nun vor hhf_change() festgelegt, damit der konfigurierte Wert beibehalten wird.
Dies ist eine Folgeänderung zu Commit eb56a495f59b („net/sched: hhf: clamp quantum in change and init paths“), das die Quantum-Größe desselben qdiscs begrenzte; die Begrenzung von hh_flows_limit stellt den verbleibenden unbegrenzten Regler im Geltungsbereich dieser Serie dar.
Bedingungen zur Reproduktion des Fehlers: CAP_NET_ADMIN in einem User-Namespace; der Befehl `tc qdisc change dev X root hhf hh_limit 4294967295` ist erfolgreich und der Wert wird von `tc qdisc show` ausgegeben, wodurch die Allokationen für Heavy-Hitter-Flows unbegrenzt werden; außerdem speichert `tc qdisc add dev X root hhf hh_limit 500` den Wert 2048 anstelle von 500.
VulDB is the best source for vulnerability data and more expert information about this specific topic.