CVE-2023-54068

In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix to call f2fswaitonpagewriteback() in f2fswriteraw_pages()

BUG_ON() will be triggered when writing files concurrently, because the same page is writtenback multiple times.

1597 void folioendwriteback(struct folio *folio) 1598 { ...... 1618 if (!__folioendwriteback(folio)) 1619 BUG(); ...... 1625 }

kernel BUG at mm/filemap.c:1619! Call Trace: <TASK> f2fswriteendio+0x1a0/0x370 blkupdaterequest+0x6c/0x410 blkmqendrequest+0x15/0x130 blkcompletereqs+0x3c/0x50 __dosoftirq+0xb8/0x29b ? sortrange+0x20/0x20 runksoftirqd+0x19/0x20 smpbootthreadfn+0x10b/0x1d0 kthread+0xde/0x110 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK>

Below is the concurrency scenario:

[Process A] [Process B] [Process C] f2fswriterawpages() - redirtypageforwritepage() - unlock page() f2fsdowritedatapage() - lockpage() - clearpagedirtyforio() - setpage_writeback() [1st writeback] ..... - unlock page()

                    generic_perform_write()
                      - f2fs_write_begin()
                        - wait_for_stable_page()

                      - f2fs_write_end()
                        - set_page_dirty()

• lock_page()
  • f2fsdowritedatapage()
    • setpagewriteback() [2st writeback]

This problem was introduced by the previous commit 7377e853967b ("f2fs: compress: fix potential deadlock of compress file"). All pagelocks were released in f2fswriteraw_pages(), but whether the page was in the writeback state was ignored in the subsequent writing process. Let's fix it by waiting for the page to writeback before writing.