CVE-2024-38306 in Linux
Sumário
de VulDB • 12/06/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
btrfs: proteger folio::private ao anexar extent buffer folios
[BUG]
Desde a versão v6.8, foram relatados crashes raros do kernel por várias pessoas; o fator comum são mensagens de erro de status incorreto da página (bad page state), como esta:
BUG: Bad page state in process kswapd0 pfn:d6e840 page: refcount:0 mapcount:0 mapping:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone=2|lastcpupid=0x3fffff) page_type: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: non-NULL mapping
[CAUSA]
O commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") altera a sequência ao alocar um novo extent buffer.
Anteriormente, sempre chamávamos grab_extent_buffer() sob mapping->i_private_lock para garantir a segurança na modificação de folio::private (que é um ponteiro para o extent buffer no caso de sectorsize regular).
Isso pode levar à seguinte race condition:
A Thread A está tentando alocar um extent buffer em bytenr X, com 4 páginas de 4K; enquanto isso, a Thread B está tentando liberar a página em X + 4K (a segunda página do extent buffer em X).
Thread A | Thread B -----------------------------------+-------------------------------------
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.