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, f2fspreparecompress_overwrite() 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 f2fsreadmulti_pages().