[PATCH 6.12.y] dm-verity: disable recursive forward error correction

[PATCH 6.12.y] dm-verity: disable recursive forward error correction

[Rahul Sharma]

From: Mikulas Patocka <mpatocka@redhat.com>

[ 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 <mpatocka@redhat.com>
Reported-by: Guangwu Zhang <guazhang@redhat.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
[ 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 <black.hawk@163.com>
---
 drivers/md/dm-verity-fec.c | 4 +---
 drivers/md/dm-verity-fec.h | 3 ---
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index 7d477ff6f26b..c55f454ff979 100644
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -424,10 +424,8 @@ int verity_fec_decode(struct dm_verity *v, struct dm_verity_io *io,
 	if (!verity_fec_is_enabled(v))
 		return -EOPNOTSUPP;
 
-	if (fio->level >= DM_VERITY_FEC_MAX_RECURSION) {
-		DMWARN_LIMIT("%s: FEC: recursion too deep", v->data_dev->name);
+	if (fio->level)
 		return -EIO;
-	}
 
 	fio->level++;
 
diff --git a/drivers/md/dm-verity-fec.h b/drivers/md/dm-verity-fec.h
index 09123a612953..ec37e607cb3f 100644
--- a/drivers/md/dm-verity-fec.h
+++ b/drivers/md/dm-verity-fec.h
@@ -23,9 +23,6 @@
 #define DM_VERITY_FEC_BUF_MAX \
 	(1 << (PAGE_SHIFT - DM_VERITY_FEC_BUF_RS_BITS))
 
-/* maximum recursion level for verity_fec_decode */
-#define DM_VERITY_FEC_MAX_RECURSION	4
-
 #define DM_VERITY_OPT_FEC_DEV		"use_fec_from_device"
 #define DM_VERITY_OPT_FEC_BLOCKS	"fec_blocks"
 #define DM_VERITY_OPT_FEC_START		"fec_start"
-- 
2.34.1

Re: [PATCH 6.12.y] dm-verity: disable recursive forward error correction

[Eric Biggers]

[+Cc dm-devel@lists.linux.dev]

On Thu, Feb 26, 2026 at 12:35:00PM +0800, Rahul Sharma wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> 
> [ 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 <mpatocka@redhat.com>
> Reported-by: Guangwu Zhang <guazhang@redhat.com>
> Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> [ 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 <black.hawk@163.com>

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