Re: [syzbot] [iomap?] kernel BUG in folio_end_read (2)

[John Ogness]

On 2025-11-05, Petr Mladek <pmladek@xxxxxxxx> wrote:
> I guess that we should do:
>
> From f9cae42b4a910127fb7694aebe2e46247dbb0fcb Mon Sep 17 00:00:00 2001
> From: Petr Mladek <pmladek@xxxxxxxx>
> Date: Wed, 5 Nov 2025 17:14:57 +0100
> Subject: [PATCH] printk_ringbuffer: Fix check of valid data size when blk_lpos
>  overflows
>
> The commit 67e1b0052f6bb8 ("printk_ringbuffer: don't needlessly wrap
> data blocks around") allows to use the last 4 bytes of the ring buffer.
>
> But the check for the data_size was not properly updated. It fails
> when blk_lpos->next overflows to "0". In this case:
>
>   + is_blk_wrapped(data_ring, blk_lpos->begin, blk_lpos->next)
>     returns false because it checks "blk_lpos->next - 1"
>
>   + but "blk_lpos->begin < blk_lpos->next" fails because
>     blk_lpos->next is already 0.
>
>   + is_blk_wrapped(data_ring, blk_lpos->begin + DATA_SIZE(data_ring),
>     blk_lpos->next) returns false because "begin_lpos" is from
>     next wrap but "next_lpos - 1" is from the previous one
>
> As a result, get_data() triggers the WARN_ON_ONCE() for "Illegal
> block description", for example:

Beautiful catch!

> Another question is whether this is the only problem caused the patch.

This comparison is quite special. It caught my attention while combing
through the code. Sadly, I missed this fix despite staring at the
problem. I was more concerned about making sure it could handle wraps
correctly without realizing it was an incorrect range check.

Tomorrow I will recomb through again, this time verifying all the range
checks.

> It might help to fill messages with a fixed size which might trigger
> blk_lpos->next == 0 in the 1st wrap.

I did this and indeed it reproduces the WARN_ON_ONCE() when next==0. And
with your patch applied, the warning is gone.

John