All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Rahul Sharma <black.hawk@163.com>
Cc: gregkh@linuxfoundation.org, stable@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@lists.linux.dev, Guangwu Zhang <guazhang@redhat.com>,
	Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH 6.12.y] dm-verity: disable recursive forward error correction
Date: Wed, 25 Feb 2026 21:04:40 -0800	[thread overview]
Message-ID: <20260226050440.GA2302@sol> (raw)
In-Reply-To: <20260226043500.3945988-1-black.hawk@163.com>

[+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

      reply	other threads:[~2026-02-26  5:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26  4:35 [PATCH 6.12.y] dm-verity: disable recursive forward error correction Rahul Sharma
2026-02-26  5:04 ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260226050440.GA2302@sol \
    --to=ebiggers@kernel.org \
    --cc=black.hawk@163.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=guazhang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=samitolvanen@google.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.