CVE-2026-64352 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
bpf : Autoriser l'accès aux cartes LPM depuis les programmes BPF dormants (sleepable)
trie_lookup_elem() annotait ses parcours via rcu_dereference_check() avec uniquement rcu_read_lock_bh_held(). Étant donné que rcu_dereference_check(p, c) se résout en « c || rcu_read_lock_held() », cela fonctionne pour les lecteurs XDP/NAPI et RCU classiques, mais échoue pour les programmes BPF dormants, qui entrent via __bpf_prog_enter_sleepable() et ne détiennent que rcu_read_lock_trace().
trie_update_elem() et trie_delete_elem() présentent le même problème sous une forme différente : ils parcourent l'arbre avec un simple rcu_dereference(), ce qui asserte rcu_read_lock_held() de manière inconditionnelle. Les deux sont accessibles depuis les programmes BPF dormants via les assistants bpf_map_update_elem / bpf_map_delete_elem, et depuis le chemin des appels système sous rcu_read_lock classique. Dans les chemins en écriture, l'arbre est réellement protégé par trie->lock (un rqspinlock pris tout au long du parcours) ; nous ne dépendions jamais de la verrouillage RCU côté lecture pour maintenir les nœuds vivants à cet endroit.
Un hook LSM dormant qui finit par toucher un arbre LPM déclenche donc lockdep sur les noyaux de débogage :
============================= AVERTISSEMENT : utilisation suspecte de RCU 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 utilisation suspecte de rcu_dereference_check() ! 1 verrou détenu par net_tests/540 : #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},
à : __bpf_prog_enter_sleepable+0x26/0x280 Pile d'appels : dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64
Il s'agit d'un problème détecté uniquement par lockdep -- pas de Use-After-Free (UAF), car Tasks Trace RCU sérialise correctement contre le chemin de récupération de l'arbre -- mais cela inonde la console une fois par site d'appel distinct sur chaque noyau de débogage exécutant un LSM BPF dormant qui touche un arbre LPM, ce qui devient de plus en plus courant.
Pour le chemin de recherche (lookup), remplacez l'annotation rcu_dereference_check() de rcu_read_lock_bh_held() vers bpf_rcu_lock_held(), qui accepte les trois contextes (classique, BH, Tasks Trace). Les autres types de cartes suivent déjà cette convention.
Pour trie_update_elem() et trie_delete_elem(), annotez les parcours comme rcu_dereference_protected(*p, 1) -- correspondant à trie_free() dans le même fichier -- puisque trie->lock est détenu tout au long du parcours. rqspinlock n'a pas de lockdep_map, donc la prédicat se réduit à « 1 » plutôt que lockdep_is_held(&trie->lock) ; la protection est réelle mais non vérifiable par machine. trie_get_next_key() utilise également un simple rcu_dereference(), mais il n'est accessible que depuis l'appel système BPF, qui détient le verrou classique rcu_read_lock() avant de dispatcher, donc il reste inchangé.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.