A Discussion Request about a maybe-false-positive of UBSAN: OOB Write in do_journal_end in Kernel 6.5-rc3(with POC)

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