Linux Kernel hasta 6.1.92/6.6.32/6.9.3 multidev f2fs_map_blocks escalada de privilegios

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
4.9$0-$5k0.00

Resumeninformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 6.1.92/6.6.32/6.9.3. Está afectada una función desconocida en el componente multidev. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase escalada de privilegios. Esta vulnerabilidad se registra como CVE-2024-38636. No existe ningún exploit disponible. Se sugiere actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 6.1.92/6.6.32/6.9.3. La función f2fs_map_blocks del componente multidev es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase escalada de privilegios. Los efectos exactos de un ataque con éxito no son conocidos. CVE resume:

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/

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-38636. Se considera difícil de explotar. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Una actualización a la versión 6.1.93, 6.6.33 o 6.9.4 elimina esta vulnerabilidad. Aplicando el parche 1a9225fdd0ec/2b2611a42462/e8b485e39b4d/33e62cd7b4c2 es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Productoinformación

Escribe

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 5.0
VulDB Puntuación meta temporal: 4.9

VulDB Puntuación base: 4.6
VulDB Puntuación temporal: 4.4
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Escalada de privilegios
CWE: CWE-697
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 6.1.93/6.6.33/6.9.4
Parche: 1a9225fdd0ec/2b2611a42462/e8b485e39b4d/33e62cd7b4c2

Línea de tiempoinformación

2024-06-18 🔍
2024-06-21 +3 días 🔍
2024-06-21 +0 días 🔍
2025-10-03 +469 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-38636 (🔍)
GCVE (CVE): GCVE-0-2024-38636
GCVE (VulDB): GCVE-100-269352

Artículoinformación

Fecha de creación: 2024-06-21 14:02
Actualizado: 2025-10-03 18:37
Cambios: 2024-06-21 14:02 (57), 2025-10-03 18:37 (13)
Completo: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Might our Artificial Intelligence support you?

Check our Alexa App!