{"id":"AZL-66614","summary":"CVE-2025-38626 affecting package kernel for versions less than 6.6.104.2-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode\n\nw/ \"mode=lfs\" mount option, generic/299 will cause system panic as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/segment.c:2835!\nCall Trace:\n \u003cTASK\u003e\n f2fs_allocate_data_block+0x6f4/0xc50\n f2fs_map_blocks+0x970/0x1550\n f2fs_iomap_begin+0xb2/0x1e0\n iomap_iter+0x1d6/0x430\n __iomap_dio_rw+0x208/0x9a0\n f2fs_file_write_iter+0x6b3/0xfa0\n aio_write+0x15d/0x2e0\n io_submit_one+0x55e/0xab0\n __x64_sys_io_submit+0xa5/0x230\n do_syscall_64+0x84/0x2f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0010:new_curseg+0x70f/0x720\n\nThe root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may\ntrigger foreground gc only if it allocates any physical block, it will be\na little bit later when there is multiple threads writing data w/\naio/dio/bufio method in parallel, since we always use OPU in lfs mode, so\nf2fs_map_blocks() does block allocations aggressively.\n\nIn order to fix this issue, let's give a chance to trigger foreground\ngc in prior to block allocation in f2fs_map_blocks().","modified":"2026-04-01T05:21:00.912245Z","published":"2025-08-22T16:15:36Z","upstream":["CVE-2025-38626"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38626"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.104.2-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-66614.json"}}],"schema_version":"1.7.5"}