[+Cc [email protected]] On Thu, Feb 26, 2026 at 12:35:00PM +0800, Rahul Sharma wrote: > From: Mikulas Patocka <[email protected]> > > [ Upstream commit d9f3e47d3fae0c101d9094bc956ed24e7a0ee801 ] > > 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 pushes dm-verity to this limit - and this > image just makes the udev-worker process get stuck in the 'D' state. > > 2. It 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. > > Signed-off-by: Mikulas Patocka <[email protected]> > Reported-by: Guangwu Zhang <[email protected]> > Reviewed-by: Sami Tolvanen <[email protected]> > Reviewed-by: Eric Biggers <[email protected]> > [ The context change is due to the commit bdf253d580d7 > ("dm-verity: remove support for asynchronous hashes") > in v6.18 which is irrelevant to the logic of this patch. ] > Signed-off-by: Rahul Sharma <[email protected]>
Looks good. The upstream patch incremented the dm target version number too, but skipping that part looks good. This further shows that the dm subsystem's version numbers don't really work. - Eric
