From: Klaus Jensen <its@irrelevant.dk>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Kaixuan Li <kaixuanli@ntu.edu.sg>,
qemu-stable@nongnu.org, Klaus Jensen <k.jensen@samsung.com>,
Keith Busch <kbusch@kernel.org>, Klaus Jensen <its@irrelevant.dk>,
Jesper Devantier <foss@defmacro.it>,
qemu-block@nongnu.org
Subject: [PULL 2/2] hw/nvme: fix heap-buffer-overflow in nvme_abort
Date: Thu, 26 Mar 2026 09:23:49 +0100 [thread overview]
Message-ID: <20260326082350.17374-3-its@irrelevant.dk> (raw)
In-Reply-To: <20260326082350.17374-1-its@irrelevant.dk>
From: Kaixuan Li <kaixuanli@ntu.edu.sg>
In nvme_abort(), the submission queue pointer is dereferenced from the
guest-controlled sqid before validating it with nvme_check_sqid():
NvmeSQueue *sq = n->sq[sqid];
Since sqid is a 16-bit value (range 0-65535) taken directly from CDW10,
and n->sq[] is typically only max_ioqpairs+1 (65) entries, a malicious
guest can trigger an out-of-bounds heap read by sending an Abort command
with a large sqid.
ASan reports this as heap-buffer-overflow in nvme_abort.
Fix this by moving the array dereference to after the nvme_check_sqid()
bounds validation.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3348
Fixes: 75209c071a ("hw/nvme: actually implement abort")
Cc: qemu-stable@nongnu.org
Signed-off-by: Kaixuan Li <kaixuanli@ntu.edu.sg>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
---
hw/nvme/ctrl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index cc4593cd427a..be6c7028cb58 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -6111,7 +6111,7 @@ static uint16_t nvme_abort(NvmeCtrl *n, NvmeRequest *req)
{
uint16_t sqid = le32_to_cpu(req->cmd.cdw10) & 0xffff;
uint16_t cid = (le32_to_cpu(req->cmd.cdw10) >> 16) & 0xffff;
- NvmeSQueue *sq = n->sq[sqid];
+ NvmeSQueue *sq;
NvmeRequest *r, *next;
int i;
@@ -6120,6 +6120,8 @@ static uint16_t nvme_abort(NvmeCtrl *n, NvmeRequest *req)
return NVME_INVALID_FIELD | NVME_DNR;
}
+ sq = n->sq[sqid];
+
if (sqid == 0) {
for (i = 0; i < n->outstanding_aers; i++) {
NvmeRequest *re = n->aer_reqs[i];
--
2.53.0
next prev parent reply other threads:[~2026-03-26 8:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 8:23 [PULL 0/2] hw/nvme fixes Klaus Jensen
2026-03-26 8:23 ` [PULL 1/2] hw/nvme: re-enable wzds bit in namespace dlfeat Klaus Jensen
2026-03-28 6:57 ` Michael Tokarev
2026-03-30 9:06 ` Klaus Jensen
2026-03-26 8:23 ` Klaus Jensen [this message]
2026-03-26 14:58 ` [PULL 0/2] hw/nvme fixes Peter Maydell
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=20260326082350.17374-3-its@irrelevant.dk \
--to=its@irrelevant.dk \
--cc=foss@defmacro.it \
--cc=k.jensen@samsung.com \
--cc=kaixuanli@ntu.edu.sg \
--cc=kbusch@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.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.