From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: linux-pci@vger.kernel.org, ntb@lists.linux.dev
Subject: Re: [PATCH v2 1/3] PCI: endpoint: Support hardware-owned MSI-X table and PBA
Date: Sun, 30 Aug 2026 15:32:44 +0000 [thread overview]
Message-ID: <20260830153245.3C6431F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830151948.3547577-2-den@valinux.co.jp>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Peer host can trigger an out-of-bounds read of the MSI-X table by sending a `db_count` larger than the locally configured `ntb->db_count`.
--
commit 295a1c24101afaf6161eaaa30348ba3941a52791
Author: Koichiro Den <den@valinux.co.jp>
PCI: endpoint: Support hardware-owned MSI-X table and PBA
Some endpoint controllers expose the MSI-X table and Pending Bit Array in
fixed, hardware-owned BAR regions. This patch introduces a new
struct pci_epc_msix_layout to describe a fixed layout where the table and
PBA have independent locations. It also updates existing EPF implementations
and callers to validate and use this new layout format.
> diff --git a/drivers/pci/endpoint/functions/pci-epf-ntb.c b/drivers/pci/endpoint/functions/pci-epf-ntb.c
> index 5314aca2188a0..f3e0e1b3ffb99 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-ntb.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-ntb.c
[ ... ]
> @@ -505,8 +504,8 @@ static int epf_ntb_configure_msix(struct epf_ntb *ntb,
> ntb_epc = ntb->epc[type];
> epc = ntb_epc->epc;
>
> - epf_bar = &ntb_epc->epf_bar[ntb_epc->msix_bar];
> - msix_tbl = epf_bar->addr + ntb_epc->msix_table_offset;
> + epf_bar = &ntb_epc->epf_bar[ntb_epc->msix_layout.table_bar];
> + msix_tbl = epf_bar->addr + ntb_epc->msix_layout.table_offset;
>
> peer_ntb_epc = ntb->epc[!type];
> peer_barno = peer_ntb_epc->epf_ntb_bar[BAR_DB_MW1];
[Severity: Critical]
This isn't a bug introduced by this patch, but can a remote peer host
trigger an out-of-bounds read that leads to arbitrary memory access?
When the remote peer host writes to its control region and provides a
db_count, it appears epf_ntb_configure_db() validates this count against
the global MAX_DB_COUNT (32) instead of the local ntb->db_count.
If the peer host sends a db_count larger than the local ntb->db_count,
could the loop in epf_ntb_configure_msix() read past the end of the
allocated msix_tbl?
for (i = 0; i < db_count; i++) {
msg_addr = ALIGN_DOWN(msix_tbl[i].msg_addr, align);
msg_data = msix_tbl[i].msg_data;
...
}
If msix_tbl is overrun, the code might read untrusted data from adjacent
memory regions (such as the peer-writable SPAD region). Since msg_addr is
then passed to pci_epc_map_addr(), could this allow the remote host to map
outbound PCIe windows to arbitrary physical memory addresses on the local
host?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830151948.3547577-1-den@valinux.co.jp?part=1
next prev parent reply other threads:[~2026-08-30 15:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 15:19 [PATCH v2 0/3] PCI: endpoint: Support hardware-owned MSI-X table and PBA Koichiro Den
2026-08-30 15:19 ` Koichiro Den
2026-08-30 15:19 ` [PATCH v2 1/3] " Koichiro Den
2026-08-30 15:19 ` Koichiro Den
2026-08-30 15:32 ` sashiko-bot [this message]
2026-08-30 15:19 ` [PATCH v2 2/3] PCI: dw-rockchip: Support fixed MSI-X table and PBA on RK3588 Koichiro Den
2026-08-30 15:19 ` Koichiro Den
2026-08-30 15:28 ` sashiko-bot
2026-08-30 15:19 ` [PATCH v2 3/3] PCI: endpoint: pci-epf-vntb: Honor MSI-X selection Koichiro Den
2026-08-30 15:19 ` Koichiro Den
2026-08-30 15:36 ` sashiko-bot
2026-08-31 10:24 ` [PATCH v2 0/3] PCI: endpoint: Support hardware-owned MSI-X table and PBA Niklas Cassel
2026-08-31 10:24 ` Niklas Cassel
2026-08-31 16:11 ` Koichiro Den
2026-08-31 16:11 ` Koichiro Den
2026-08-31 20:01 ` Niklas Cassel
2026-08-31 20:01 ` Niklas Cassel
2026-09-02 2:14 ` Koichiro Den
2026-09-02 2:14 ` Koichiro Den
2026-09-02 7:25 ` Niklas Cassel
2026-09-02 7:25 ` Niklas Cassel
2026-09-03 7:56 ` Koichiro Den
2026-09-03 7:56 ` Koichiro Den
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=20260830153245.3C6431F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=den@valinux.co.jp \
--cc=linux-pci@vger.kernel.org \
--cc=ntb@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.