CVE-2026-90302 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ocfs2 : synchroniser les rappels du heartbeat avec l'arrêt d'o2net
Série de correctifs "ocfs2: durcissement des conditions de course lors de l'arrêt du heartbeat".
Cette série corrige deux conditions de race (races) liées à l'arrêt du heartbeat/o2net dans OCFS2, détectées par KASAN.
Ce correctif (sur 2) :
Les rappels du heartbeat restent enregistrés alors que le processus d'arrêt local via configfs entre dans `o2net_stop_listening()`. Un événement de déconnexion d'un nœud peut toujours s'exécuter à travers `o2net_disconnect_node()` et `o2net_set_nn_state()` pendant que l'arrêt détruit la file de travail o2net_wq, ce qui signifie que les opérations ultérieures de mise en file ou de vidage (flush) peuvent toucher une file de travail morte. KASAN a détecté cela comme un use-after-free sur le slab dans `__queue_work()` avec la trace d'appels suivante :
KASAN slab-use-after-free in __queue_work+0x56/0xa90 Lecture de taille 4 Trace d'appels (Call trace) : dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30
Alloué par la pile des tâches : kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f
Libéré par la pile des tâches : kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660
queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list
Conserver les rappels du heartbeat enregistrés afin que l'état de quorum suive toujours l'état des nœuds, mais empêcher leur exécution pour le travail de reconnexion/déconnexion o2net une fois que l'arrêt local commence. Marquer le transport comme hors ligne avant de détruire o2net_wq, attendre la fin de tout rappel du heartbeat en cours d'exécution (in-flight), et reporter la rejoue (replay) jusqu'à ce que le nouveau nœud local soit publié via `o2nm_this_node()`.
La rejoue doit également rester sérialisée avec la livraison des rappels du heartbeat. Sinon, un instantané de nœud actif peut être copié, un vrai rappel hb_down peut installer -ENOTCONN pour un pair, et la rejoue obsolète peut appeler `o2net_hb_node_up()` pour ce même pair et mettre en file le travail de reconnexion bien que le heartbeat soit déjà hors ligne.
Le scénario bogué implique deux chemins d'exécution, chaque colonne montrant l'ordre au sein de ce chemin :
Arrêt du nœud local : Rappel de déconnexion de nœud (heartbeat node-down) : 1. configfs local-off entre 1. o2hb_run_event_list() invoque dans o2net_stop_listening(). o2net_hb_node_down_cb(). 2. L'arrêt se dirige vers 2. le rappel atteint destroy_workqueue(o2net_wq). o2net_disconnect_node() et o2net_set_nn_state(). 3. L'arrêt détruit et met à NULL 3. le rappel vide ou met en file o2net_wq. du travail via o2net_wq.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.