CVE-2026-99204 in Linux
Riassunto
di VulDB • 28/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ocfs2/dlm: Proteggere l'elenco di recupero durante le letture da debugfs.
I record dei partecipanti al recupero devono rimanere validi mentre `debug_state_print()` attraversa i dati del nodo (`reco.node_data`) e formatta i relativi campi. Il formatter mantiene il lock `dlm->spinlock`, ma la lista dei partecipanti al recupero è protetta dal lock `dlm_reco_state_lock`. In particolare, `dlm_destroy_recovery_area()` stacca l'elenco sotto `dlm_reco_state_lock` e libera i record staccati dopo aver rilasciato tale lock. Un'apertura concorrente di debugfs può quindi leggere memoria già liberata (slab-use-after-free).
Proteggere la traversa dei partecipanti e le letture dei campi in `debug_state_print()` con `dlm_reco_state_lock`, allineandosi agli scrittori dell'elenco esistenti. Ciò serializza anche la traversa rispetto a `list_add_tail()` durante l'inizializzazione dell'area di recupero. Rendere il lock esistente disponibile al codice di debug attraverso `dlmcommon.h`; il lock rimane interno al modulo OCFS2 DLM.
Rilasciare `dlm->spinlock` dopo la formattazione dello stato degli altri domini e prima di acquisire `dlm_reco_state_lock`, in modo che il lettore di debug non annidi i due lock. L'inserimento, lo stacco e la liberazione dell'elenco di recupero rimangono invariati.
Segnalazione KASAN come segue:
BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896
CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.]
</TASK>
Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0)
[Page and memory-state dumps omitted.]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.