CVE-2024-38636

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: multidev: fix to recognize valid zero block address<br /> <br /> As reported by Yi Zhang in mailing list [1], kernel warning was catched<br /> during zbd/010 test as below:<br /> <br /> ./check zbd/010<br /> zbd/010 (test gap zone support with F2FS) [failed]<br /> runtime ... 3.752s<br /> something found in dmesg:<br /> [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13<br /> [ 4378.192349] null_blk: module loaded<br /> [ 4378.209860] null_blk: disk nullb0 created<br /> [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim<br /> poll_queues to 0. poll_q/nr_hw = (0/1)<br /> [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]<br /> dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0<br /> [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux<br /> scsi_debug 0191 PQ: 0 ANSI: 7<br /> [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred<br /> [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20<br /> [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device<br /> ...<br /> (See &amp;#39;/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg&amp;#39;<br /> <br /> WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51<br /> CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1<br /> RIP: 0010:iomap_iter+0x32b/0x350<br /> Call Trace:<br /> <br /> __iomap_dio_rw+0x1df/0x830<br /> f2fs_file_read_iter+0x156/0x3d0 [f2fs]<br /> aio_read+0x138/0x210<br /> io_submit_one+0x188/0x8c0<br /> __x64_sys_io_submit+0x8c/0x1a0<br /> do_syscall_64+0x86/0x170<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Shinichiro Kawasaki helps to analyse this issue and proposes a potential<br /> fixing patch in [2].<br /> <br /> Quoted from reply of Shinichiro Kawasaki:<br /> <br /> "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a<br /> look in the commit, but it looks fine to me. So I thought the cause is not<br /> in the commit diff.<br /> <br /> I found the WARN is printed when the f2fs is set up with multiple devices,<br /> and read requests are mapped to the very first block of the second device in the<br /> direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()<br /> modify map-&gt;m_pblk as the physical block address from each block device. It<br /> becomes zero when it is mapped to the first block of the device. However,<br /> f2fs_iomap_begin() assumes that map-&gt;m_pblk is the physical block address of the<br /> whole f2fs, across the all block devices. It compares map-&gt;m_pblk against<br /> NULL_ADDR == 0, then go into the unexpected branch and sets the invalid<br /> iomap-&gt;length. The WARN catches the invalid iomap-&gt;length.<br /> <br /> This WARN is printed even for non-zoned block devices, by following steps.<br /> <br /> - Create two (non-zoned) null_blk devices memory backed with 128MB size each:<br /> nullb0 and nullb1.<br /> # mkfs.f2fs /dev/nullb0 -c /dev/nullb1<br /> # mount -t f2fs /dev/nullb0 "${mount_dir}"<br /> # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192<br /> # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct<br /> <br /> ..."<br /> <br /> So, the root cause of this issue is: when multi-devices feature is on,<br /> f2fs_map_blocks() may return zero blkaddr in non-primary device, which is<br /> a verified valid block address, however, f2fs_iomap_begin() treats it as<br /> an invalid block address, and then it triggers the warning in iomap<br /> framework code.<br /> <br /> Finally, as discussed, we decide to use a more simple and direct way that<br /> checking (map.m_flags &amp; F2FS_MAP_MAPPED) condition instead of<br /> (map.m_pblk != NULL_ADDR) to fix this issue.<br /> <br /> Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this<br /> issue.<br /> <br /> [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/<br /> [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/