Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode[EOL][EOL]w/ "mode=lfs" mount option, generic/299 will cause system panic as below:[EOL][EOL]------------[ cut here ]------------[EOL]kernel BUG at fs/f2fs/segment.c:2835![EOL]Call Trace:[EOL] <TASK>[EOL] f2fs_allocate_data_block+0x6f4/0xc50[EOL] f2fs_map_blocks+0x970/0x1550[EOL] f2fs_iomap_begin+0xb2/0x1e0[EOL] iomap_iter+0x1d6/0x430[EOL] __iomap_dio_rw+0x208/0x9a0[EOL] f2fs_file_write_iter+0x6b3/0xfa0[EOL] aio_write+0x15d/0x2e0[EOL] io_submit_one+0x55e/0xab0[EOL] __x64_sys_io_submit+0xa5/0x230[EOL] do_syscall_64+0x84/0x2f0[EOL] entry_SYSCALL_64_after_hwframe+0x76/0x7e[EOL]RIP: 0010:new_curseg+0x70f/0x720[EOL][EOL]The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may[EOL]trigger foreground gc only if it allocates any physical block, it will be[EOL]a little bit later when there is multiple threads writing data w/[EOL]aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so[EOL]f2fs_map_blocks() does block allocations aggressively.[EOL][EOL]In order to fix this issue, let's give a chance to trigger foreground[EOL]gc in prior to block allocation in f2fs_map_blocks().

CREATE(Triage):(User=pbi-cn) [CVE-2025-38626 (https://nvd.nist.gov/vuln/detail/CVE-2025-38626)