Re: [PATCH] ocfs2: validate truncate log dinode before caching

[ZhengYuan Huang]

On Wed, Jul 22, 2026 at 8:56 PM Joseph Qi <joseph.qi@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 7/22/26 5:11 PM, ZhengYuan Huang wrote:
> > [BUG]
> > A corrupted truncate log dinode can pass through mount initialization and
> > reach the delayed flush worker, where it triggers:
> >
> > kernel BUG at fs/ocfs2/alloc.c:6019!
> > Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> > RIP: 0010:__ocfs2_flush_truncate_log+0xa87/0xf10 fs/ocfs2/alloc.c:6019
> > Call Trace:
> >  ocfs2_flush_truncate_log fs/ocfs2/alloc.c:6084 [inline]
> >  ocfs2_truncate_log_worker+0xa9/0x180 fs/ocfs2/alloc.c:6097
> >  process_one_work+0x8e0/0x1980 kernel/workqueue.c:3263
> >  ...
> >
>
> I've encountered this BUG occasionality. But I don't see why it happens.
> Do you have more clues on how to reproduce it?
>
> Thanks,
> Joseph

Thanks for looking into this.

This bug was originally found by our fuzzing tool. We tried to
reproduce it using the automatically saved disk image and syscall
program, but so far we have been unable to reproduce the BUG in
__ocfs2_flush_truncate_log directly. Instead, the same artifacts have
triggered two other issues:

KASAN: use-after-free Read in ocfs2_dx_dir_search
kernel BUG in ocfs2_grow_tree

For the use-after-free in ocfs2_dx_dir_search, I previously submitted
a patch that addresses what I believe is its root cause:

https://lore.kernel.org/all/20260416082105.1295887-1-gality369@xxxxxxxxx/

However, I have not received any feedback on the patch yet, and at
this point we are not sure whether that issue is related to the
truncate-log corruption reported here.

We are continuing to investigate and will share any new findings. In
the meantime, the original artifacts generated by our fuzzer are
available here:

https://drive.google.com/file/d/1zCJoUb2uwVqTrGIM4JFLbwkcHRz04TJo/view?usp=sharing

The archive contains the disk image, the PoC program, and a kernel
log. To run the reproducer, mount the supplied disk image and execute
the PoC. Please note that, in our current tests, these artifacts can
trigger the two issues mentioned above, but they do not reproduce the
BUG in __ocfs2_flush_truncate_log. The archive also includes the
kernel log captured when the original BUG occurred, which may help
with further investigation.

Thanks,
ZhengYuan Huang