CVE-2024-38636: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-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] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 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:iomap_iter+0x32b/0x350 Call Trace: <TASK> __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 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, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk 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) null_blk devices memory backed with 128MB size each: nullb0 and 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 ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() 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.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != 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/

AI Analysis

Technical Summary

CVE-2024-38636 is a vulnerability identified in the Linux kernel's F2FS (Flash-Friendly File System) implementation, specifically affecting the multi-device (multidev) feature. The issue arises from improper handling of physical block addresses when multiple devices are used. In this scenario, the function f2fs_map_blocks() may return a zero block address for the first block of a non-primary device, which is a valid physical block address. However, the function f2fs_iomap_begin() incorrectly interprets this zero value as an invalid address (NULL_ADDR) and subsequently triggers a warning due to an invalid iomap length. This misinterpretation leads to kernel warnings and potential instability during file read operations, particularly in direct I/O paths. The vulnerability was discovered through kernel testing (blktests) and analyzed by contributors Yi Zhang and Shinichiro Kawasaki, who proposed a fix that changes the validation logic to check a mapping flag (F2FS_MAP_MAPPED) instead of relying on the physical block address being non-zero. This fix prevents false warnings and ensures correct handling of valid zero block addresses across multiple devices. The vulnerability affects Linux kernel versions including 6.8.0-rc3+ and potentially others using the multidev feature in F2FS. While no known exploits are reported in the wild, the issue can cause kernel warnings and potentially impact system stability or performance during I/O operations on affected systems.

Potential Impact

For European organizations, the impact of CVE-2024-38636 primarily concerns systems running Linux kernels with F2FS configured in multi-device mode. This includes environments utilizing zoned block devices or setups with multiple storage devices managed under F2FS. The vulnerability can lead to kernel warnings and potentially unstable I/O operations, which may cause application errors, degraded performance, or system crashes under heavy I/O workloads. Organizations relying on Linux servers for critical infrastructure, cloud services, or data centers could experience disruptions if affected systems encounter this issue. Although the vulnerability does not directly enable privilege escalation or remote code execution, the resulting instability could affect availability and reliability of services. Given the widespread use of Linux in European enterprises, especially in sectors like finance, telecommunications, and government, any instability in storage subsystems could have operational and reputational consequences. However, the impact is limited to systems using the specific F2FS multidev feature, which is less common than other file systems, somewhat reducing the overall risk footprint.

Mitigation Recommendations

To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patch that addresses the issue by modifying the validation logic in the F2FS multidev code, as proposed by the kernel developers. 2) Update Linux kernel versions to the latest stable releases that include this fix, avoiding use of release candidates or older kernels with the vulnerability. 3) Audit systems to identify those using F2FS with multi-device configurations, especially those employing zoned block devices or null_blk devices for testing, and prioritize patching these systems. 4) Implement monitoring for kernel warnings related to iomap or F2FS to detect potential triggering of this issue in production environments. 5) For environments where immediate patching is not feasible, consider disabling the multi-device feature in F2FS or migrating critical workloads to more stable file systems until the fix can be applied. 6) Engage with Linux distribution vendors to ensure timely delivery of patched kernel packages and coordinate updates in managed environments.