On Mon, 17 Nov 2025, Sami Tolvanen wrote:

> Hi Mikulas,
> 
> On Fri, Nov 14, 2025 at 7:54 AM Mikulas Patocka <[email protected]> wrote:
> >
> > Hi
> >
> > What do you think about this patch?
> >
> > There are two problems with the recursive correction:
> >
> > 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that
> > has 253 iterations. For each iteration, we may call verity_hash_for_block
> > recursively. There is a limit of 4 nested recursions - that means that
> > there may be at most 253^4 (4 billion) iterations. Red Hat QE team
> > actually created an image that that pushes dm-verity to this limit - and
> > this image just makes the udev-worker process get stuck in the 'D' state.
> >
> > 2. It probably doesn't work. In fec_read_bufs we store data into the
> > variable "fio->bufs", but fio bufs is shared between recursive
> > invocations, if "verity_hash_for_block" invoked correction recursively, it
> > would overwrite partially filled fio->bufs.
> >
> > So, I'm suggesting to remove recursive correction at all. This patch
> > passed the cryptsetup testsuite. Does it pass your tests too?
> >
> > Signed-off-by: Mikulas Patocka <[email protected]>
> > Reported-by: Guangwu Zhang <[email protected]>
> 
> This looks reasonable to me. I only remember seeing recursive error
> correction trigger in a real system when someone attempts to use the
> wrong root hash, which is obviously not recoverable.
> 
> Reviewed-by: Sami Tolvanen <[email protected]>
> 
> Sami

Thanks, OK.

I staged the patch for 6.19.

Mikulas

Reply via email to