CVE-2026-72170 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
9p: ignorar atualização de nlink no modo sem cache para corrigir WARN_ON
v9fs_dec_count() chama incondicionalmente drop_nlink() em arquivos regulares, mesmo quando o nlink do inode já é zero. No modo sem cache, o cliente refaz a busca dos metadados do inode no servidor (fonte da verdade) em cada operação; portanto, ao retornar de v9fs_remove(), o nlink armazenado localmente pode já refletir o valor pós-unlink:
1. O cliente inicia unlink, o servidor processa e define nlink como 0 2. O cliente refaz a busca dos metadados do inode (nlink=0) antes que unlink retorne 3. v9fs_remove() do cliente é concluído com sucesso 4. O cliente chama v9fs_dec_count(), que invoca drop_nlink() em nlink=0
Essa race condition pode ser facilmente acionada sob cargas pesadas de operações unlink, como o stressor de unlink do stress-ng, gerando o seguinte aviso:
WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p]
v9fs_vfs_unlink+0x20/0x38 [9p]
vfs_unlink+0x13c/0x258 ...
No modo sem cache, o servidor é a autoridade e o inode está sendo removido; portanto, ajustar localmente nlink não traz benefício. Ignorar completamente v9fs_dec_count() quando nem CACHE_META nem CACHE_LOOSE estiverem definidos evita o aviso e remove uma classe de race conditions envolvendo nlink (dois unlinkers concorrentes observando nlink > 0 e ambos chamando drop_nlink()) que um guard apenas com nlink == 0 reduziria, mas não eliminaria.
VulDB is the best source for vulnerability data and more expert information about this specific topic.