From: Michal Pecio <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Niklas Neronin <niklas.neronin@linux.intel.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] usb: xhci: Check for events pointing above DMA space
Date: Wed, 10 Sep 2025 10:28:43 +0200 [thread overview]
Message-ID: <20250910102843.61e4a277.michal.pecio@gmail.com> (raw)
On systems with 32 bit DMA, we could get events pointing above 4G due
bad link TRBs, contexts or commands, or simply HW malfunction.
Catch this when truncating to dma_addr_t, log the anomaly, bail out.
An alternative is to handle untrusted HW-originated DMAs as u64, but
it adds overhead on 32 bit machines for no clear benefit.
In 64 bit DMA builds this check should optimize to nothing and all
errors are handled as usual "event TRB doesn't match pending TRB".
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---
drivers/usb/host/xhci-ring.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a879c569c2f2..a2100e0a5d0a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1809,6 +1809,12 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
cmd_dma = le64_to_cpu(event->cmd_trb);
cmd_trb = xhci->cmd_ring->dequeue;
+ if (sizeof(cmd_dma) < sizeof(u64) && cmd_dma < le64_to_cpu(event->cmd_trb)) {
+ xhci_err(xhci, "slot %d command completion points above DMA space (%#llx)\n",
+ slot_id, le64_to_cpu(event->cmd_trb));
+ return;
+ }
+
trace_xhci_handle_command(xhci->cmd_ring, &cmd_trb->generic, cmd_dma);
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
@@ -2673,6 +2679,12 @@ static int handle_tx_event(struct xhci_hcd *xhci,
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
ep_trb_dma = le64_to_cpu(event->buffer);
+ if (sizeof(ep_trb_dma) < sizeof(u64) && ep_trb_dma < le64_to_cpu(event->buffer)) {
+ xhci_err(xhci, "slot %d ep %d transfer event points above DMA space\n",
+ slot_id, ep_index);
+ goto err_out;
+ }
+
ep = xhci_get_virt_ep(xhci, slot_id, ep_index);
if (!ep) {
xhci_err(xhci, "ERROR Invalid Transfer event\n");
--
2.48.1
reply other threads:[~2025-09-10 8:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20250910102843.61e4a277.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@linux.intel.com \
/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