CVE-2026-98644 in Linux
Zusammenfassung
von VulDB • 18.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bpf: Vermeidung von Soft-Lockups in __htab_map_lookup_and_delete_batch()
__htab_map_lookup_and_delete_batch() verfügt über keinen Rescheduling-Punkt (Punkt für die Wiederaufnahme der Planung). Die Batch-Anzahl begrenzt, wie viele Einträge kopiert werden, nicht jedoch, wie viele Buckets durchlaufen werden. Daher kann ein einziger BPF_MAP_LOOKUP_BATCH-Aufruf die Map von Anfang bis Ende durchlaufen. Der Fast-Path für leere Buckets ist noch problematischer: Er verbleibt innerhalb eines einzelnen rcu_read_lock() / bpf_disable_instrumentation()-Abschnitts für jede Folge aufeinanderfolgender leerer Buckets.
Dies führt bei kleinen Maps zu Engpässen, bricht jedoch im großen Maßstab zusammen. Auf einem 144-CPU-arm64-Host mit einem CONFIG_PREEMPT_NONE-Kernel hielten periodische BPF_MAP_LOOKUP_BATCH-Aufrufe gegen eine LRU-Hashmap mit 16.777.216 Buckets eine CPU für über 77 Sekunden in der Batch-Operation fest und lösten den Soft-Lockup-Watchdog aus.
Das Commit 75134f16e7dd („bpf: Add schedule points in batch ops“) behob dieses gleiche Problem bei den generischen Batch-Vorgängen, jedoch nicht im htab-nativen Pfad, der von jeder auf htab basierenden Hashmap-Variante für ihre lookup[_and_delete]-Batch-Vorgänge verwendet wird.
Schließen Sie diese Korrektur hier ab. Verlassen Sie den kritischen Abschnitt nach 64 aufeinanderfolgenden leeren Buckets, rufen Sie cond_resched_tasks_rcu_qs() auf und setzen Sie die Ausführung am gespeicherten Bucket-Cursor fort. Zu diesem Zeitpunkt werden keine Locks gehalten, und das Fortsetzen vom Cursor aus entspricht bereits dem Verhalten der Funktion für nicht-leere Buckets. Fügen Sie denselben Aufruf in die pro-Bucket-Schleife nach copy_to_user() ein, wo alle Locks freigegeben wurden. cond_resched_rcu() reicht hier nicht aus: Das Schlafen mit aktiviertem bpf_prog_active führt dazu, dass Tracing-Programme auf dieser CPU ihre Aufrufe stillschweigend überspringen.
Auch einfaches cond_resched() ist nicht ausreichend. Es ist unter PREEMPT und PREEMPT_LAZY ein No-op (keine Operation), die einzigen Modelle, die arm64 und x86 seit dem Commit 7dadeaa6e851 („sched: Further restrict the preemption modes“) angeboten haben. Zudem stellt es in keinem Modell einen Tasks-RCU-quiescent state (Ruhezustand) dar: Das Rescheduling zählt als Preemption. Die durchlaufende Aufgabe bleibt ein Ausreißer und blockiert jeden Aufrufer von synchronize_rcu_tasks(), einschließlich ftrace und dem Abbau des BPF-Trampolins, bis der Systemaufruf zurückkehrt [1]. cond_resched_tasks_rcu_qs() ist das übliche Werkzeug dafür [2]. Es meldet den quiescent state bei jedem Yield (Kontextwechsel) und führt weiterhin ein Rescheduling durch, wie es cond_resched() auf PREEMPT_NONE- und PREEMPT_VOLUNTARY-Kernels tut.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.