CVE-2026-99204 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ocfs2/dlm: Proteger a lista de recuperação durante leituras no debugfs
Os registros dos participantes da recuperação devem permanecer válidos enquanto `debug_state_print()` percorre os dados do nó (`reco.node_data`) e formata seus campos. O formatador mantém o bloqueio `dlm->spinlock`, mas a lista de participantes da recuperação é protegida por `dlm_reco_state_lock`. Especificamente, `dlm_destroy_recovery_area()` desanexa a lista sob `dlm_reco_state_lock` e libera os registros desanexados após soltá-lo. Uma abertura concorrente no debugfs pode, portanto, ler memória já liberada (use-after-free).
Proteja o percurso dos participantes e as leituras de campos em `debug_state_print()` com `dlm_reco_state_lock`, correspondendo aos escritores existentes da lista. Isso também serializa o percurso contra `list_add_tail()` durante a inicialização da área de recuperação. Torne o bloqueio existente disponível para o código de depuração através do arquivo `dlmcommon.h`; o bloqueio permanece interno ao módulo OCFS2 DLM.
Solte `dlm->spinlock` após formatar o estado dos outros domínios e antes de adquirir `dlm_reco_state_lock`, para que o leitor de depuração não anide os dois bloqueios. Deixe a inserção, desanexação e liberação da lista de recuperação inalteradas.
Relatório KASAN conforme abaixo:
BUG: KASAN: slab-use-after-free em debug_state_open+0x1169/0x12d0 Leitura de tamanho 4 no endereço ffff88810662ef80 pela tarefa dlm-state-stres/896
CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Não contaminado (Not tainted) 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Nome do hardware: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Rastreamento de chamada: <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 [Registro de registradores omitido.]
</TASK>
Alocado pela tarefa 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
Liberado pela tarefa 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
O endereço com defeito pertence ao objeto em ffff88810662ef80, que pertence à cache kmalloc-32 de tamanho 32. O endereço com defeito está localizado a 0 bytes dentro da região liberada de 32 bytes [ffff88810662ef80, ffff88810662efa0).
[Dumps de página e estado da memória omitidos.]
If you want to get best quality of vulnerability data, you may have to visit VulDB.