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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: authentication: Fix use-after-free en ubifs_tnc_end_commit Después de una inserción en TNC, el árbol podría dividirse y hacer que un nodo cambie su `znode->parent`. Una eliminación adicional de otros nodos en el árbol (que también podría liberar los nodos), el `znode->cparent` del nodo mencionado anteriormente aún podría apuntar a un nodo liberado. Este `znode->cparent` puede no actualizarse al hacer que los nodos se comprometan en `ubifs_tnc_start_commit()`. Esto podría desencadenar un use-after-free al acceder a `znode->cparent` en `write_index()` en `ubifs_tnc_end_commit()`. Esto se puede activar ejecutando rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync en un bucle y con `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN luego informa: ERROR: KASAN: use-after-free en ubifs_tnc_end_commit+0xa5c/0x1950 Escritura de tamaño 32 en la dirección ffffff800a3af86c por la tarea ubifs_bgt0_20/153 Rastreo de llamadas: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 Asignado por la tarea 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 escritura_caché_páginas+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c intervalo_de_escritura_y_espera_de_archivo+0x140/0x190 ubifs_fsync+0xe8/0x290 intervalo_de_fsync_vfs+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invocar_llamada_al_sistema.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Liberado por la tarea 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 El `memcpy()` ofensivo en `ubifs_copy_hash()` tiene un use-after-free cuando un nodo se convierte en raíz en TNC pero aún tiene un `cparent` para un nodo ya liberado. Más específicamente, considere la siguiente TNC: zroot // zp1 // zn Insertar un nuevo nodo `zn_new` con una clave menor que `zn` activará una división en `tnc_insert()` si `zp1` está lleno: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn `zn->parent` ahora se ha movido a `zp2`, *pero* `zn->cparent` todavía apunta a `zp1`. Ahora, considere una eliminación de todos los nodos _excepto_ `zn`. Justo cuando `tnc_delete()` está a punto de eliminar `zroot` y `zp2`: zroot \ \ zp2 \ \ zn `zroot` y `zp2` se liberan y el árbol colapsa: zn `zn` ahora se convierte en el nuevo `zroot`. `get_znodes_to_commit()` ahora solo encontrará `zn`, el nuevo `zroot`, y `write_index()` verificará su `znode->cparent` que apunta erróneamente al `zp1` ya liberado. Por lo tanto, `ubifs_copy_hash()` se llama erróneamente con `znode->cparent->zbranch[znode->iip].hash` que activa el use-after-free. Solucione esto configurando explícitamente `znode->cparent` en `NULL` en `get_znodes_to_commit()` para el nodo raíz. La búsqueda de los nodos sucios ---truncada---