mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: dm-devel@lists.linux.dev, Alasdair Kergon <agk@redhat.com>,
	 Mike Snitzer <snitzer@kernel.org>,
	 Benjamin Marzinski <bmarzins@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dm: fix excessive blk-crypto operations for invalid keys
Date: Wed, 21 Jan 2026 17:55:55 +0100 (CET)	[thread overview]
Message-ID: <5cd121df-1f26-b484-f991-eeaaa33e767d@redhat.com> (raw)
In-Reply-To: <20260117030236.96871-1-ebiggers@kernel.org>

Accepted, thanks.

Mikulas


On Fri, 16 Jan 2026, Eric Biggers wrote:

> dm_exec_wrappedkey_op() passes through the derive_sw_secret, import_key,
> generate_key, and prepare_key blk-crypto operations to an underlying
> device.
> 
> Currently, it calls the operation on every underlying device until one
> returns success.
> 
> This logic is flawed when the operation is expected to fail, such as an
> invalid key being passed to derive_sw_secret.  That can happen if
> userspace passes an invalid key to the FS_IOC_ADD_ENCRYPTION_KEY ioctl.
> 
> When that happens on a device-mapper device that consists of many
> dm-linear targets, a lot of unnecessary key unwrapping requests get sent
> to the underlying key wrapping hardware.
> 
> Fix this by considering the first device only.  As already documented in
> the comment, it was already checked that all underlying devices support
> wrapped keys, so this should be fine.
> 
> Fixes: e93912786e50 ("dm: pass through operations on wrapped inline crypto keys")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>  drivers/md/dm-table.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> index 0522cd700e0e..4b70872725d0 100644
> --- a/drivers/md/dm-table.c
> +++ b/drivers/md/dm-table.c
> @@ -1235,13 +1235,10 @@ static int dm_wrappedkey_op_callback(struct dm_target *ti, struct dm_dev *dev,
>  	struct block_device *bdev = dev->bdev;
>  	struct blk_crypto_profile *profile =
>  		bdev_get_queue(bdev)->crypto_profile;
>  	int err = -EOPNOTSUPP;
>  
> -	if (!args->err)
> -		return 0;
> -
>  	switch (args->op) {
>  	case DERIVE_SW_SECRET:
>  		err = blk_crypto_derive_sw_secret(
>  					bdev,
>  					args->derive_sw_secret.eph_key,
> @@ -1264,13 +1261,11 @@ static int dm_wrappedkey_op_callback(struct dm_target *ti, struct dm_dev *dev,
>  					     args->prepare_key.lt_key_size,
>  					     args->prepare_key.eph_key);
>  		break;
>  	}
>  	args->err = err;
> -
> -	/* Try another device in case this fails. */
> -	return 0;
> +	return 1; /* No need to continue the iteration. */
>  }
>  
>  static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile,
>  				 struct dm_wrappedkey_op_args *args)
>  {
> @@ -1292,18 +1287,17 @@ static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile,
>  	 * implementations of wrapped inline crypto keys on a single system.
>  	 * It was already checked earlier that support for wrapped keys was
>  	 * declared on all underlying devices.  Thus, all the underlying devices
>  	 * should support all wrapped key operations and they should behave
>  	 * identically, i.e. work with the same keys.  So, just executing the
> -	 * operation on the first device on which it works suffices for now.
> +	 * operation on the first device suffices for now.
>  	 */
>  	for (i = 0; i < t->num_targets; i++) {
>  		ti = dm_table_get_target(t, i);
>  		if (!ti->type->iterate_devices)
>  			continue;
> -		ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args);
> -		if (!args->err)
> +		if (ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args) != 0)
>  			break;
>  	}
>  out:
>  	dm_put_live_table(md, srcu_idx);
>  	return args->err;
> 
> base-commit: fb8a6c18fb9a6561f7a15b58b272442b77a242dd
> -- 
> 2.52.0
> 


      reply	other threads:[~2026-01-21 16:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17  3:02 Eric Biggers
2026-01-21 16:55 ` Mikulas Patocka [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=5cd121df-1f26-b484-f991-eeaaa33e767d@redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=ebiggers@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®