Dear Developers and Maintainers, We would like to report a Linux kernel bug titled "BUG: unable to handle kernel paging request in const_folio_flags" found in Linux-6.14-rc7 by our modified tool. We have reproduced the crash and applied a patch that can avoid the kernel panic. Here are the relevant attachments: kernel config: https://drive.google.com/file/d/1vHuHlQyiKlXbyuo03sZTiuaA5jZ5MtV6/view?usp=sharing report: https://drive.google.com/file/d/11LD1uFid1u3r7brsvd85-SrBzvXwH-w2/view?usp=sharing syz reproducer: https://drive.google.com/file/d/10v3FtkewHcAnTjsUGqFCDl7k7hiCJ12-/view?usp=sharing C reproducer: https://drive.google.com/file/d/1L9WTVbO2pfqXLjXyQcMy4f-Am3obTJcN/view?usp=sharing crash log: https://drive.google.com/file/d/1zwYU3061pnTSVIEpuZ-EBR7FYvWPxX4z/view?usp=sharing We speculate this vulnerability arises from a missing check for error pointers in the array folios[i] within the function ocfs2_unlock_and_free_folios(). When the kernel fails to write or allocate folios for writing (e.g., due to OOM), the wc->w_folios[i] may be assigned an error pointer (e.g., -ENOMEM) in fs/ocfs2/aops.c:1075, which is then returned as an error to ocfs2_write_begin_nolock(). Within ocfs2_unlock_and_free_folios(), there is no proper handling for error pointers, so the function attempts to process folios[i] directly. This results in the kernel attempting to dereference an invalid pointer during the call chain: ocfs2_unlock_and_free_folios->folio_unlock->folio_test_locked->const_folio_flags. Specifically, during debugging, we observe that the kernel attempts to read data from rbx+0x8 (where rbx = 0xfffffffffffffff4), causing a page fault and kernel panic. I tested the following patch, which prevents the kernel panic by checking for error pointers before accessing folios[i]: --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -767,7 +767,7 @@ void ocfs2_unlock_and_free_folios(struct folio **folios, int num_folios) int i; for(i = 0; i < num_folios; i++) { - if (!folios[i]) + if (!folios[i] || IS_ERR(folios[i])) // or use IS_ERR_OR_NULL instead continue; folio_unlock(folios[i]); folio_mark_accessed(folios[i]); However, I am not sure if the analysis and patch are appropriate. Could you check this issue? With the verification, I would like to submit a patch. Wish you a nice day! Best, Zhiyu Zhang
