CVE-2024-38636

{"id": "CVE-2024-38636", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-06-21T11:15:12.317", "references": [{"url": "https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: multidev: fix to recognize valid zero block address\n\nAs reported by Yi Zhang in mailing list [1], kernel warning was catched\nduring zbd/010 test as below:\n\n./check zbd/010\nzbd/010 (test gap zone support with F2FS) [failed]\n runtime ... 3.752s\n something found in dmesg:\n [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13\n [ 4378.192349] null_blk: module loaded\n [ 4378.209860] null_blk: disk nullb0 created\n [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim\npoll_queues to 0. poll_q/nr_hw = (0/1)\n [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]\n dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0\n [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux\nscsi_debug 0191 PQ: 0 ANSI: 7\n [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred\n [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20\n [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device\n ...\n (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'\n\nWARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51\nCPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1\nRIP: 0010:iomap_iter+0x32b/0x350\nCall Trace:\n <TASK>\n __iomap_dio_rw+0x1df/0x830\n f2fs_file_read_iter+0x156/0x3d0 [f2fs]\n aio_read+0x138/0x210\n io_submit_one+0x188/0x8c0\n __x64_sys_io_submit+0x8c/0x1a0\n do_syscall_64+0x86/0x170\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nShinichiro Kawasaki helps to analyse this issue and proposes a potential\nfixing patch in [2].\n\nQuoted from reply of Shinichiro Kawasaki:\n\n\"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a\nlook in the commit, but it looks fine to me. So I thought the cause is not\nin the commit diff.\n\nI found the WARN is printed when the f2fs is set up with multiple devices,\nand read requests are mapped to the very first block of the second device in the\ndirect read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()\nmodify map->m_pblk as the physical block address from each block device. It\nbecomes zero when it is mapped to the first block of the device. However,\nf2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the\nwhole f2fs, across the all block devices. It compares map->m_pblk against\nNULL_ADDR == 0, then go into the unexpected branch and sets the invalid\niomap->length. The WARN catches the invalid iomap->length.\n\nThis WARN is printed even for non-zoned block devices, by following steps.\n\n - Create two (non-zoned) null_blk devices memory backed with 128MB size each:\n nullb0 and nullb1.\n # mkfs.f2fs /dev/nullb0 -c /dev/nullb1\n # mount -t f2fs /dev/nullb0 \"${mount_dir}\"\n # dd if=/dev/zero of=\"${mount_dir}/test.dat\" bs=1M count=192\n # dd if=\"${mount_dir}/test.dat\" of=/dev/null bs=1M count=192 iflag=direct\n\n...\"\n\nSo, the root cause of this issue is: when multi-devices feature is on,\nf2fs_map_blocks() may return zero blkaddr in non-primary device, which is\na verified valid block address, however, f2fs_iomap_begin() treats it as\nan invalid block address, and then it triggers the warning in iomap\nframework code.\n\nFinally, as discussed, we decide to use a more simple and direct way that\nchecking (map.m_flags & F2FS_MAP_MAPPED) condition instead of\n(map.m_pblk != NULL_ADDR) to fix this issue.\n\nThanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this\nissue.\n\n[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/\n[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/"}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: f2fs: multidev: correcci\u00f3n para reconocer una direcci\u00f3n de bloque cero v\u00e1lida. Seg\u00fan lo informado por Yi Zhang en la lista de correo [1], se detect\u00f3 una advertencia del kernel durante la prueba zbd/010 como se muestra a continuaci\u00f3n: ./check zbd/010 zbd/010 (probar soporte de zona de brecha con F2FS) [fall\u00f3] tiempo de ejecuci\u00f3n... 3.752s algo encontrado en dmesg: [4378.146781] ejecutar blktests zbd/010 en 2024-02-18 11:31:13 [4378.192349] null_blk: m\u00f3dulo 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\u00f3n 019 1 [20210520] dev_size_mb= 1024, opciones = 0x0, enviar_colas = 1, estad\u00edsticas = 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\u00e9rico 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\u00f3n en [2] . Citado de la respuesta de Shinichiro Kawasaki: \"Confirm\u00e9 que el commit desencadenante es dbf8e63f48af como inform\u00f3 Yi. Ech\u00e9 un vistazo al compromiso, pero me parece bien. As\u00ed que pens\u00e9 que la causa no est\u00e1 en la diferencia de compromiso. Encontr\u00e9 el WARN se imprime cuando f2fs est\u00e1 configurado con m\u00faltiples 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-&gt;m_pblk como. la direcci\u00f3n del bloque f\u00edsico de cada dispositivo de bloque se vuelve cero cuando se asigna al primer bloque del dispositivo. Sin embargo, f2fs_iomap_begin() asume que map-&gt;m_pblk es la direcci\u00f3n del bloque f\u00edsico de todo el f2fs, en todos los dispositivos de bloque. Compara map-&gt;m_pblk con NULL_ADDR == 0, luego ingresa a la rama inesperada y establece la longitud iomap-&gt; no v\u00e1lida. La ADVERTENCIA detecta la longitud iomap-&gt; no v\u00e1lida. 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\u00f1o 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\u00f3n de dispositivos est\u00e1 activada, f2fs_map_blocks() puede devolver cero blkaddr en un dispositivo no principal, que es una direcci\u00f3n de bloque v\u00e1lida verificada; sin embargo, f2fs_iomap_begin() la trata como una direcci\u00f3n de bloque no v\u00e1lida y luego activa la advertencia en el c\u00f3digo del marco iomap Finalmente, como se mencion\u00f3, decidimos utilizar una forma m\u00e1s simple y directa que verificar la condici\u00f3n (map.m_flags &amp; 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/"}], "lastModified": "2025-10-03T14:55:23.893", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "899D7A4F-A23D-4FA2-84B4-4BAA03F98BBC", "versionEndExcluding": "6.1.93", "versionStartIncluding": "5.17"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "FCE796DF-3B50-4DC6-BAE5-95271068FC9E", "versionEndExcluding": "6.6.33", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "991B9791-966A-4D18-9E8D-A8AB128E5627", "versionEndExcluding": "6.9.4", "versionStartIncluding": "6.7"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}