In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in preparecompressoverwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in _f2fswritedatapages() and the test hangs. The options I used are: MKFSOPTIONS -- -O compression -O extraattr -O projectquota -O quota /dev/vdc MOUNTOPTIONS -- -o acl,userxattr -o discard,compressextension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 taskflags:0x4208160 flags:0x00004000 Workqueue: writeback wbworkfn (flush-253:0) Call Trace: <TASK> _schedule+0x309/0x8e0 schedule+0x3a/0x100 schedulepreemptdisabled+0x15/0x30 _mutexlock+0x59a/0xdb0 _f2fswritedatapages+0x3ac/0x400 dowritepages+0xe8/0x290 _writebacksingleinode+0x5c/0x360 writebacksbinodes+0x22f/0x570 wbwriteback+0xb0/0x410 wbdowriteback+0x47/0x2f0 wbworkfn+0x5a/0x1c0 processonework+0x223/0x5b0 workerthread+0x1d5/0x3c0 kthread+0xfd/0x230 retfromfork+0x31/0x50 retfromforkasm+0x1a/0x30 </TASK> The root cause is: once generic/475 starts toload error table to dm device, f2fspreparecompressoverwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fshandlepageeio() in preparecompressoverwrite() to detect IO error. - detect cperror earler in f2fsreadmultipages().