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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: multidev: corrección para reconocer una dirección de bloque cero válida. Según lo informado por Yi Zhang en la lista de correo [1], se detectó una advertencia del kernel durante la prueba zbd/010 como se muestra a continuación: ./check zbd/010 zbd/010 (probar soporte de zona de brecha con F2FS) [falló] tiempo de ejecución... 3.752s algo encontrado en dmesg: [4378.146781] ejecutar blktests zbd/010 en 2024-02-18 11:31:13 [4378.192349] null_blk: módulo cargado [4378.209860] null_blk: disco nullb0 creado [4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: recortar poll_queues a 0. poll_q/nr_hw = (0/1) [4378.422334] scsi host15: scsi_debug: versión 019 1 [20210520] dev_size_mb= 1024, opciones = 0x0, enviar_colas = 1, estadísticas = 0 [4378.434922] scsi 15:0:0:0: Acceso directo-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [4378.443343] scsi 15:0:0:0 : Se produjo el encendido o el restablecimiento del dispositivo [ 4378.449371] sd 15:0:0:0: SCSI genérico sg5 tipo 20 adjunto [ 4378.449418] sd 15:0:0:0: [sdf] Dispositivo de bloqueo de zonas administrado por host... (Consulte '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' ADVERTENCIA: CPU: 22 PID : 44011 en fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio No contaminado 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Seguimiento de llamadas: __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 Entry_SYSCALL_64_after_hwframe +0x6e/0x76 Shinichiro Kawasaki ayuda a analizar este problema y propone un posible parche de solución en [2] . Citado de la respuesta de Shinichiro Kawasaki: "Confirmé que el commit desencadenante es dbf8e63f48af como informó Yi. Eché un vistazo al compromiso, pero me parece bien. Así que pensé que la causa no está en la diferencia de compromiso. Encontré el WARN se imprime cuando f2fs está configurado con múltiples dispositivos y las solicitudes de lectura se asignan al primer bloque del segundo dispositivo en la ruta de lectura directa. En este caso, f2fs_map_blocks() y f2fs_map_blocks_cached() modifican map->m_pblk como. la dirección del bloque físico de cada dispositivo de bloque se vuelve cero cuando se asigna al primer bloque del dispositivo. Sin embargo, f2fs_iomap_begin() asume que map->m_pblk es la dirección del bloque físico de todo el f2fs, en todos los dispositivos de bloque. Compara map->m_pblk con NULL_ADDR == 0, luego ingresa a la rama inesperada y establece la longitud iomap-> no válida. La ADVERTENCIA detecta la longitud iomap-> no válida. Esta ADVERTENCIA se imprime incluso para dispositivos de bloque no zonificados. siguiendo los siguientes pasos: - Cree dos dispositivos null_blk con memoria respaldada con un tamaño de 128 MB cada uno: nullb0 y nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs =1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." Entonces, la causa principal de este problema es: cuando -la función de dispositivos está activada, f2fs_map_blocks() puede devolver cero blkaddr en un dispositivo no principal, que es una dirección de bloque válida verificada; sin embargo, f2fs_iomap_begin() la trata como una dirección de bloque no válida y luego activa la advertencia en el código del marco iomap Finalmente, como se mencionó, decidimos utilizar una forma más simple y directa que verificar la condición (map.m_flags & F2FS_MAP_MAPPED) en lugar de (map.m_pblk! = NULL_ADDR) para solucionar este problema. y Shinichiro Kawasaki sobre este tema [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel. org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/