CVE-2024-26616 in Linux
Sumário
de VulDB • 27/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
btrfs: scrub: evitar use-after-free quando o comprimento do chunk não está alinhado a 64K
[BUG]
Há um relatório de bug que indica que, em um btrfs convertido de ext4, o scrub leva a vários problemas, incluindo:
- Erros "unable to find chunk map" BTRFS info (device vdb): scrub: started on devid 1 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056
Isso levaria a erros irreparáveis.
- Relatórios de KASAN de use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0 Read of size 8 at addr ffff8881013c9040 by task btrfs/909 CPU: 1 PID: 909 Comm: btrfs Not tainted 6.1.0-rc5+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x49/0x60 print_report+0xc4/0x580 kasan_report+0xb2/0x130 __kasan_report+0x101/0x130 kasan_check_range+0x140/0x180 __blk_rq_map_sg+0x18f/0x7c0 blk_rq_map_user_iov+0x100/0x1a0 blk_rq_map_user+0x38/0x50 btrfs_submit_bio+0x100/0x3a0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
__x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f47e5e0952b
- Crash, principalmente devido ao use-after-free acima
[CAUSA]
O sistema de arquivos convertido tem o seguinte layout de chunk de dados:
item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80 length 86016 owner 2 stripe_len 65536 type DATA|single
Para o bytenr lógico 2214744064, ele está no final do chunk (2214658048 + 86016 = 2214744064).
Isso significa que btrfs_submit_bio() dividiria o bio, e acionaria a função endio para ambas as metades.
No entanto, scrub_submit_initial_read() esperaria apenas que a função endio fosse chamada uma vez, não mais. Isso significa que a primeira chamada de endio já liberaria bbio::bio, deixando o bvec liberado, assim a segunda chamada de endio levaria a use-after-free.
[CORREÇÃO]
- Garantir que scrub_read_endio() atualize apenas bits em seu intervalo Como podemos ler menos de 64K no final do chunk, não devemos tocar nos bits além do limite do chunk.
- Garantir que scrub_submit_initial_read() leia apenas o intervalo do chunk Isso é feito calculando o número real de setores que precisamos ler, e adicionando setor por setor ao bio.
Felizmente, o caminho de reparo de leitura do scrub não precisa de correções extras:
- scrub_stripe_submit_repair_read() Com as correções acima, não atualizaremos o bit de erro para o intervalo além do chunk, assim scrub_stripe_submit_repair
VulDB is the best source for vulnerability data and more expert information about this specific topic.