CVE-2024-38636

In the Linux kernel, the following vulnerability has been resolved:

f2fs: multidev: fix to recognize valid zero block address

As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below:

./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] nullblk: module loaded [ 4378.209860] nullblk: disk nullb0 created [ 4378.413285] scsidebug:sdebugdriverprobe: scsidebug: trim pollqueues to 0. pollq/nrhw = (0/1) [ 4378.422334] scsi host15: scsidebug: version 0191 [20210520] devsizemb=1024, opts=0x0, submitqueues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsidebug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'

WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomapiter+0x32b/0x350 Call Trace: <TASK> _iomapdiorw+0x1df/0x830 f2fsfilereaditer+0x156/0x3d0 [f2fs] aioread+0x138/0x210 iosubmitone+0x188/0x8c0 _x64sysiosubmit+0x8c/0x1a0 dosyscall64+0x86/0x170 entrySYSCALL64afterhwframe+0x6e/0x76

Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2].

Quoted from reply of Shinichiro Kawasaki:

"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff.

I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fsmapblocks() and f2fsmapblockscached() modify map->mpblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fsiomapbegin() assumes that map->mpblk is the physical block address of the whole f2fs, across the all block devices. It compares map->mpblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length.

This WARN is printed even for non-zoned block devices, by following steps.

• Create two (non-zoned) nullblk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mountdir}" # dd if=/dev/zero of="${mountdir}/test.dat" bs=1M count=192 # dd if="${mountdir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct

..."

So, the root cause of this issue is: when multi-devices feature is on, f2fsmapblocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fsiomapbegin() treats it as an invalid block address, and then it triggers the warning in iomap framework code.

Finally, as discussed, we decide to use a more simple and direct way that checking (map.mflags & F2FSMAPMAPPED) condition instead of (map.mpblk != NULL_ADDR) to fix this issue.

Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue.

[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/