CVE-2026-98507 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/rmap: corrige barreira de memória ausente entre a inicialização de anon_vma e a publicação de vma->anon_vma
Em servidores arm64, observamos que uma tarefa tentando adquirir o bloqueio (lock) de anon_vma aciona um hungtask.
INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180
Após analisar o vmcore, descobrimos que anon_vma->root->rwsem.count é -1. Há outro anon_vma cujo anon_vma->root->rwsem.count é 1; o campo owner de anon_vma->root->rwsem indica que o bloqueio está sendo mantido (held), mas a stack da tarefa mostra que ela não possui o bloqueio de anon_vma.
Após adicionar mais informações de depuração, descobrimos que __anon_vma_prepare() reutiliza anon_vma e aciona um Use-After-Free (UAF) em anon_vma->root devido à ausência de barreira de memória, levando ao travamento e desbloqueio de dois diferentes anon_vma->roots. Isso resulta em um anon_vma nunca sendo desbloqueado e outro anon_vma não podendo mais ser bloqueado.
Essa race condition requer duas VMAs adjacentes que não são mescladas, mas são compatíveis com anon_vma (por exemplo, diferem nos VMA_ACCESS_FLAGS, que podem ser alterados por mprotect()). Duas threads falham em cada VMA simultaneamente, ambas chamando __anon_vma_prepare() com apenas o mmap_lock mantido para leitura.
THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem);
A thread A aciona uma falha de página e chama __anon_vma_prepare() para preparar o anon_vma para a vma que causou a falha. O __anon_vma_prepare() aloca e inicializa um novo anon_vma, em seguida o publica na vma com uma operação de armazenamento (store) simples. O anon_vma_prepare() requer apenas que o mmap_lock esteja mantido para leitura, portanto duas threads podem sofrer falhas em VMAs adjacentes ao mesmo tempo. Enquanto a thread A publica um novo anon_vma, a thread B pode encontrar o anon_vma via find_mergeable_anon_vma() e então bloquear anon_vma->root->rwsem.
O armazenamento (store) em anon_vma->root em anon_vma_alloc() e o armazenamento em vma->anon_vma podem ser reordenados. O anon_vma_lock_write() e spin_lock() fornecem apenas semântica de aquisição (acquire semantics), que não impedem que armazenamentos anteriores sejam reordenados após eles. As semânticas de liberação (release) do correspondente spin_unlock() e anon_vma_unlock_write() chegam tarde demais; o armazenamento em vma->anon_vma já foi publicado antes que entrem em vigor. Como resultado, a thread B pode observar a seguinte ordem:
vma->anon_vma = anon_vma; anon_vma->root = anon_vma;
O slab de anon_vma é SLAB_TYPESAFE_BY_RCU, portanto um novo anon_vma alocado pode reutilizar memória de um anteriormente liberado. O construtor (anon_vma_ctor) não redefine anon_vma->root, e o __put_anon_vma() também não o limpa; assim, o valor antigo do root persiste até que anon_vma_alloc() o sobrescreva. Se esse armazenamento não for v ---truncated---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.