All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Sungwoo Kim <iam@sung-woo.kim>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Subject: Re: [PATCH] nvme: remove bogus check in nvme_pr_read_keys()
Date: Mon, 23 Mar 2026 11:53:23 -0600	[thread overview]
Message-ID: <acF-E8csusg-YbaO@kbusch-mbp> (raw)
In-Reply-To: <ab5yUf3BqtlN3K-P@stanley.mountain>

On Sat, Mar 21, 2026 at 01:26:25PM +0300, Dan Carpenter wrote:
> This check for if (rse_len > U32_MAX) is confusing because if
> rse_len is > INT_MAX, that will trigger a WARN() in kvzalloc().
> Fortunately, the caller blkdev_pr_read_keys(), puts a limit on num_keys.
> The number of keys can't be more than PR_KEYS_MAX (65536) and the
> condition is impossible.

There's actually two callers: blkdev_pr_read_keys() ensures the number of
keys is smaller than 65536 and iblock_pr_read_keys() is a fixed size at
16. But begs the question, what guarantee does nvme_pr_read_keys() have
that all the callers validated the number of keys such that it can
bravely skip checking it? I think nvme should validate that it's a
reasonable value before calling kvalloc so we return an apporpriate
EINVAL instead of ENOMEM. The existing UINT_MAX check is certainly far
too high, but I think something like a 4MB payload would be a totally
reasonable upper limit for nvme on this function.


  reply	other threads:[~2026-03-23 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-21 10:26 [PATCH] nvme: remove bogus check in nvme_pr_read_keys() Dan Carpenter
2026-03-23 17:53 ` Keith Busch [this message]
2026-03-24  6:53   ` Christoph Hellwig
2026-03-24  7:05   ` Dan Carpenter

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=acF-E8csusg-YbaO@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dan.carpenter@linaro.org \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=hch@lst.de \
    --cc=iam@sung-woo.kim \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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.