cveboard Feed RSS

CVE-2024-35784

CVE.org · Publicado

Histórico de CVEsJSONInstruções para IA

Status do registro
Publicado
Ano do identificador (não é o ano de publicação)
2024
Publicação na fonte
Atualização na fonte
Importado pelo cveboard
Snapshot da fonte
cve_2026-10-24_midnight_baseline ·

Texto simples

Texto da CNA em inglês

btrfs: fix deadlock with fiemap and extent locking

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase.

Fatos de produtos e versões por escopo

Dados de correção desconhecidos; nenhuma versão corrigida é deduzida aqui. Dados ausentes não comprovam ausência de correção.

Exploração desconhecida; este catálogo não avalia exploração.

Linux

Fornecedor
Linux
Produto
Linux
Plataformas
Desconhecido
Status padrão
unaffected
Linux · Fatos de produtos e versões por escopo
Versão (version)Status (status)Esquema de versões (versionType)Fim exclusivo (lessThan)Fim inclusivo (lessThanOrEqual)Mudanças de status (at → status)
1506fcc8189cdd4b95e06df7845a09f18b4526a6affectedgitded566b4637f1b6b4c9ba74e7d0b8493e93f19cfIndisponívelNenhuma listada
1506fcc8189cdd4b95e06df7845a09f18b4526a6affectedgit89bca7fe6382d61e88c67a0b0e7bce315986fb8bIndisponívelNenhuma listada
1506fcc8189cdd4b95e06df7845a09f18b4526a6affectedgitb0ad381fa7690244802aed119b478b4bdafc31ddIndisponívelNenhuma listada

Linux

Fornecedor
Linux
Produto
Linux
Plataformas
Desconhecido
Status padrão
affected
Linux · Fatos de produtos e versões por escopo
Versão (version)Status (status)Esquema de versões (versionType)Fim exclusivo (lessThan)Fim inclusivo (lessThanOrEqual)Mudanças de status (at → status)
2.6.29affectedIndisponívelIndisponívelIndisponívelNenhuma listada
0unaffectedsemver2.6.29IndisponívelNenhuma listada
6.6.24unaffectedsemverIndisponível6.6.*Nenhuma listada
6.7.12unaffectedsemverIndisponível6.7.*Nenhuma listada
6.8unaffectedoriginal_commit_for_fixIndisponível*Nenhuma listada