Hi UpStream Community, I found a UBSAN: OOB Write in do_journal_end reported on Linux Kernel 6.5-rc3 by my modified version of syzkaller on 25 July. I tried to send an email, but it was rejected by the mail system due to HTML formatting included in the email. Here is the plain email text: The .config, report*, repro.prog, repro.cprog can be found in: https://drive.google.com/file/d/1GPN68s6mA0Ee3CyK7OSbdBNABuFEzhtv/view?usp=sharing And the POC can be stably reproduced in the latest kernel (in/after 6.5-rc3) and the kernel panics. Reproduced screenshot: https://drive.google.com/file/d/10_4PQHSSwEBCHIMDxjb9EzB6UylRjocP/view?usp=sharing After analyzing the root cause, I found it may be a false-positive of UBSAN. Firstly, the oob behavior happened at fs/reiserfs/journal.c:4166. When i == 1, it overwrites the desc->j_realblock[i], which is declared with a size of 1. However, with a further sight, the desc is wrapped with a b_size=0x1000 when allocating and i won't be larger than trans_half (smaller than blocksize), which would prevent the overwriting at line 4166. It seems a trick of memory access of j_realblock. But in fs/reiserfs/journal.c:4169, is it possible to manually construct an extremely long journal link and let i-trans_half > 0x1000? In this way, commit->j_realblock[i - trans_half] = cpu_to_le32(cn->bh->b_blocknr); may destroy the memory outside the block "barrier". And maybe conduct a heap spray? I'm not sure if it's actually an fp, so I haven't patched it yet. I hope to have some discussion based on my analysis. Thanks for your time reading this discussion request. Although I'm a newbie in kernel security, I am very glad to help to improve the kernel. Best regards! Zhiyu Zhang
