Vulnerabilidad en kernel de Linux (CVE-2024-35784)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto con fiemap y bloqueo de extensión Mientras trabajaba en el conjunto de parches para eliminar el bloqueo de extensión, obtuve un lockdep splat con fiemap y pagefaulting con mi nuevo bloqueo de reemplazo de bloqueo de extensión. Este punto muerto existe con nuestro código normal, simplemente no tenemos anotaciones de bloqueo con el bloqueo de extensión, por lo que nunca lo hemos notado. Dado que copiamos la extensión del mapa de archivos al espacio del usuario en cada iteración, tenemos la posibilidad de que se produzcan errores de página. Debido a que mantenemos el bloqueo de extensión para todo el rango, podemos escribir en un rango en el archivo que hemos asignado. Esto se bloquearía con el siguiente seguimiento de pila [<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>] extend_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 Escribí un fstest para reproducir este interbloqueo sin mi bloqueo de reemplazo y verifiqué que existe un punto muerto con nuestro bloqueo existente. Para solucionar este problema, simplemente no utilice el bloqueo de extensión durante toda la duración del mapa de archivos. En general, esto es seguro porque realizamos un seguimiento de dónde estamos cuando buscamos en el árbol, por lo que si una extensión ordenada se actualiza en medio de nuestra llamada a fiemap, seguiremos emitiendo las extensiones correctas porque sabemos en qué desplazamiento estábamos. antes. El único lugar donde mantenemos el bloqueo es buscando en delalloc. Dado que las cosas de delalloc pueden cambiar durante la reescritura, queremos bloquear el rango de extensión para tener una vista consistente de delalloc en el momento en que verificamos si necesitamos configurar el indicador delalloc. Con este parche aplicado ya no nos estancamos con mi caso de prueba.