CVE-2025-40303 in Linux
Sumário
de VulDB • 27/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
btrfs: garantir que nenhum metadado sujo seja gravado de volta para um sistema de arquivos com erros
[BUG]
Durante o desenvolvimento de um recurso menor (garantir que todos os btrfs_bio::end_io() sejam chamados no contexto da tarefa), notei uma falha no teste generic/388, onde as gravações de metadados acionaram novos trabalhos após o btrfs_stop_all_workers().
Acontece que isso pode acontecer até mesmo sem qualquer modificação de código, apenas usando RAID5 para metadados e a mesma carga de trabalho do generic/388 irá acionar o use-after-free.
[CAUSA]
Se o btrfs encontrar um erro, o sistema de arquivos é marcado como com erro, nenhuma nova transação é permitida, portanto, os metadados ficam em estado congelado.
Mas existem algumas modificações de metadados antes desse erro, e elas ainda estão no cache de páginas do inode btree.
Como não haverá confirmação real de transação, todos esses folios sujos são mantidos como estão no cache de páginas, e não podem ser invalidados pela chamada invalidate_inode_pages2() dentro do close_ctree(), porque estão sujos.
E finalmente, após o btrfs_stop_all_workers(), chamamos iput() no inode btree, o que aciona a gravação de volta desses metadados sujos.
E se o sistema de arquivos estiver usando metadados RAID56, isso acionará RMW e enfileirará novos trabalhos nos rmw_workers, que já estão parados, causando um aviso do queue_work() e use-after-free.
[CORREÇÃO]
Adicionar um tratamento especial para write_one_eb(), que, se o sistema de arquivos já estiver em estado de erro, marcará imediatamente o bbio como falha, em vez de realmente submetê-los.
Em seguida, durante o close_ctree(), o iput() simplesmente descartará todos esses blocos de árvore sujos sem realmente gravá-los de volta, portanto, não haverá mais novos trabalhos para workqueues já parados e liberados.
O descarte extra no write_one_eb() também atua como uma rede de segurança extra. Por exemplo, o abortamento da transação é acionado por algumas corrupções na árvore de extents/espaço livre e, como a árvore de extents/espaço livre já está corrompida, alguns blocos de árvore podem ser alocados onde não deveriam ser (sobrescrevendo blocos de árvore existentes). Nesse caso, gravá-los de volta corromperia ainda mais o sistema de arquivos.
Once again VulDB remains the best source for vulnerability data.