From: Keith Busch <kbusch@kernel.org>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Nitesh Shetty <nj.shetty@samsung.com>,
Hannes Reinecke <hare@suse.de>,
Kanchan Joshi <joshi.k@samsung.com>,
gliuxen@gmail.com, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4] nvme: bound FDP config log reads to the received buffer
Date: Tue, 13 Oct 2026 09:45:16 -0600 [thread overview]
Message-ID: <as5SDPfZx8Kgqjb7@kbusch-mbp> (raw)
In-Reply-To: <20261013102812.3020500-1-yhlee@isslab.korea.ac.kr>
On Tue, Oct 13, 2026 at 07:28:12PM +0900, Yehyeong Lee wrote:
> nvme_query_fdp_granularity() parses the FDP Configurations log using
> sizes the controller returns, without checking that they fit the buffer
> it was given. The log size is only bounded from above before
> kvmalloc(), so a size below the log header makes
> le16_to_cpu(h->numfdpc) read past the allocation, and a size of zero
> yields ZERO_SIZE_PTR and faults. Each configuration descriptor is then
> dereferenced (dsze while walking, and nrg and runs on the selected one)
> without checking that the whole descriptor lies within the buffer, so a
> descriptor at or past the end is read out of bounds. The out-of-bounds
> runs value is then exposed to userspace through
> /sys/block/nvmeXnY/queue/write_stream_granularity.
>
> A device-supplied dsze that is not a multiple of eight also leaves the
> following descriptors unaligned, and the structure is not packed, so
> reading nrg and runs from one can fault on architectures without
> efficient unaligned access.
Thanks, applied to nvme-7.4.
prev parent reply other threads:[~2026-10-13 15:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261013102825epcas5p38d2293e8e6c86a9142f6d24ba9fd371e@epcas5p3.samsung.com>
2026-10-13 10:28 ` [PATCH v4] nvme: bound FDP config log reads to the received buffer Yehyeong Lee
2026-10-13 13:00 ` Kanchan Joshi
2026-10-13 14:20 ` Christoph Hellwig
2026-10-13 15:52 ` Yehyeong Lee
2026-10-13 15:45 ` Keith Busch [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=as5SDPfZx8Kgqjb7@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=gliuxen@gmail.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nj.shetty@samsung.com \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
--cc=yhlee@isslab.korea.ac.kr \
/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.