CVE-2026-98644 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
bpf : Éviter un blocage logiciel (soft lockup) dans __htab_map_lookup_and_delete_batch()
La fonction __htab_map_lookup_and_delete_batch() ne comporte aucun point de planification (rescheduling). Le compteur par lot détermine le nombre d'entrées copiées vers l'utilisateur, et non le nombre de seaux visités ; ainsi, un seul appel BPF_MAP_LOOKUP_BATCH peut parcourir la carte dans son intégralité. La voie rapide pour les seaux vides est encore plus problématique : elle reste à l'intérieur d'une seule section rcu_read_lock() / bpf_disable_instrumentation() pendant toute une séquence de seaux vifs consécutifs.
Cela pose problème sur les petites cartes, mais devient critique à grande échelle. Sur un hôte arm64 disposant de 144 CPU et exécutant un noyau CONFIG_PREEMPT_NONE, des appels périodiques BPF_MAP_LOOKUP_BATCH effectués contre une carte hash LRU comportant 16 777 216 seaux ont maintenu un CPU à l'intérieur de l'opération par lot pendant plus de 77 secondes, déclenchant le garde-fou (watchdog) de blocage logiciel.
Le commit 75134f16e7dd (« bpf: Add schedule points in batch ops ») a corrigé ce même problème dans les opérations par lot génériques, mais pas dans cette voie native htab, qui est utilisée par toutes les variantes de cartes hash basées sur htab pour leurs opérations par lot lookup[_and_delete].
Apportez ici la correction complète. Quittez la section critique après 64 seaux vifs consécutifs, appelez cond_resched_tasks_rcu_qs(), et reprenez l'exécution au curseau de seau sauvegardé. Aucun verrou n'est détenu à ce stade, et la reprise depuis le curseau correspond déjà au comportement de la fonction pour les seaux non vides. Ajoutez le même appel dans la boucle par seau après copy_to_user(), où tous les verrous ont été relâchés. cond_resched_rcu() ne suffit pas ici : dormir avec bpf_prog_active élevé fait que les programmes de traçage sur ce CPU sautent silencieusement leurs invocations.
cond_resched() simple n'est également pas suffisant. Il s'agit d'un non-opération (no-op) sous PREEMPT et PREEMPT_LAZY, les seuls modèles qu'arm64 et x86 ont proposés depuis le commit 7dadeaa6e851 (« sched: Further restrict the preemption modes »). De plus, il ne constitue jamais un état de quiétude RCU pour les tâches (Tasks RCU) dans aucun modèle : la planification compte comme une préemption. La tâche en cours d'itération reste bloquée et met en attente tous les appelants de synchronize_rcu_tasks(), y compris le teardown des trampolines ftrace et BPF, jusqu'à ce que l'appel système revienne [1]. cond_resched_tasks_rcu_qs() est l'outil habituel pour résoudre cela [2]. Il signale l'état de quiétude à chaque cession (yield) tout en planifiant toujours comme le fait cond_resched() sur les noyaux PREEMPT_NONE et PREEMPT_VOLUNTARY.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.