All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-kernel@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Mike Christie <michael.christie@oracle.com>,
	linux-nvme@lists.infradead.org, Jens Axboe <axboe@kernel.dk>,
	linux-scsi@vger.kernel.org, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH v2 2/4] nvme: reject invalid pr_read_keys() num_keys values
Date: Mon, 1 Dec 2025 11:22:55 -0500	[thread overview]
Message-ID: <20251201162255.GD866564@fedora> (raw)
In-Reply-To: <20251201063649.GB19461@lst.de>

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Mon, Dec 01, 2025 at 07:36:49AM +0100, Christoph Hellwig wrote:
> On Thu, Nov 27, 2025 at 10:54:22AM -0500, Stefan Hajnoczi wrote:
> > The pr_read_keys() interface has a u32 num_keys parameter. The NVMe
> > Reservation Report command has a u32 maximum length. Reject num_keys
> > values that are too large to fit.
> > 
> > This will become important when pr_read_keys() is exposed to untrusted
> > userspace via an <linux/pr.h> ioctl.
> > 
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >  drivers/nvme/host/pr.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/nvme/host/pr.c b/drivers/nvme/host/pr.c
> > index ca6a74607b139..156a2ae1fac2e 100644
> > --- a/drivers/nvme/host/pr.c
> > +++ b/drivers/nvme/host/pr.c
> > @@ -233,6 +233,10 @@ static int nvme_pr_read_keys(struct block_device *bdev,
> >  	int ret, i;
> >  	bool eds;
> >  
> > +	/* Check that keys fit into u32 rse_len */
> > +	if (num_keys > (U32_MAX - sizeof(*rse)) / sizeof(rse->regctl_eds[0]))
> > +		return -EINVAL;
> > +
> 
> We use struct_size to calculate the size below, which saturates on
> overflow.  So just checking the rse_len variable returned by the that
> would be nicer.  Bonus points for using sizeof_field() instead of
> hardcoding U32_MAX.

Will fix. I don't see how to use sizeof_field() here, but taking
advantage of struct_size() already improves things a lot:

diff --git a/drivers/nvme/host/pr.c b/drivers/nvme/host/pr.c
index ca6a74607b139..ad2ecc2f49a97 100644
--- a/drivers/nvme/host/pr.c
+++ b/drivers/nvme/host/pr.c
@@ -228,7 +228,8 @@ static int nvme_pr_resv_report(struct block_device *bdev, void *data,
 static int nvme_pr_read_keys(struct block_device *bdev,
                struct pr_keys *keys_info)
 {
-       u32 rse_len, num_keys = keys_info->num_keys;
+       size_t rse_len;
+       u32 num_keys = keys_info->num_keys;
        struct nvme_reservation_status_ext *rse;
        int ret, i;
        bool eds;
@@ -238,6 +239,9 @@ static int nvme_pr_read_keys(struct block_device *bdev,
         * enough to get enough keys to fill the return keys buffer.
         */
        rse_len = struct_size(rse, regctl_eds, num_keys);
+       if (rse_len > U32_MAX)
+               return -EINVAL;
+
        rse = kzalloc(rse_len, GFP_KERNEL);
        if (!rse)
                return -ENOMEM;

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-12-01 16:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27 15:54 [PATCH v2 0/4] block: add IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION ioctls Stefan Hajnoczi
2025-11-27 15:54 ` [PATCH v2 1/4] scsi: sd: reject invalid pr_read_keys() num_keys values Stefan Hajnoczi
2025-11-27 18:03   ` Hannes Reinecke
2025-12-01  6:34   ` Christoph Hellwig
2025-12-01 15:09     ` Stefan Hajnoczi
2025-12-01 16:23     ` Stefan Hajnoczi
2025-11-27 15:54 ` [PATCH v2 2/4] nvme: " Stefan Hajnoczi
2025-11-27 18:04   ` Hannes Reinecke
2025-12-01  6:36   ` Christoph Hellwig
2025-12-01 16:22     ` Stefan Hajnoczi [this message]
2025-12-02  5:55       ` Christoph Hellwig
2025-12-01  7:11   ` Chaitanya Kulkarni
2025-12-01  7:27     ` Christoph Hellwig
2025-11-27 15:54 ` [PATCH v2 3/4] block: add IOC_PR_READ_KEYS ioctl Stefan Hajnoczi
2025-11-27 18:06   ` Hannes Reinecke
2025-12-01  6:40   ` Christoph Hellwig
2025-12-01 16:33     ` Stefan Hajnoczi
2025-11-27 15:54 ` [PATCH v2 4/4] block: add IOC_PR_READ_RESERVATION ioctl Stefan Hajnoczi
2025-12-01  6:40   ` Christoph Hellwig
2025-11-29 21:44 ` [PATCH v2 0/4] block: add IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION ioctls Martin K. Petersen

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=20251201162255.GD866564@fedora \
    --to=stefanha@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --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.