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 09/11] NTB/msi: Require a singleton memory window
Date: Mon, 03 Aug 2026 18:23:22 +0000 [thread overview]
Message-ID: <20260803182323.4E5901F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803180439.1963864-10-den@valinux.co.jp>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Error Handling Bug: incorrect memory window index cleared on rollback
- [High] Integer Underflow / Out-of-Bounds Read: Negative index passed to hardware driver
--
--- Patch [9]: [PATCH 09/11] NTB/msi: Require a singleton memory window ---
commit ed42871f4aa60b4cc0fd8192c14055c9e382384b
Author: Koichiro Den <den@valinux.co.jp>
NTB/msi: Require a singleton memory window
This commit adds a check in ntb_msi_init() to reject NTB MSI layouts
where the outbound memory window does not form a singleton translation
group. This ensures the transport driver can retain non-singleton groups
for data use.
> diff --git a/drivers/ntb/msi.c b/drivers/ntb/msi.c
> index 6817d504c12ac..029edcf400784 100644
> --- a/drivers/ntb/msi.c
> +++ b/drivers/ntb/msi.c
[ ... ]
> @@ -42,6 +44,21 @@ int ntb_msi_init(struct ntb_dev *ntb,
> if (peers <= 0)
> return -EINVAL;
>
> + if (ntb->ops->mw_get_trans_group) {
> + for (i = 0; i < peers; i++) {
> + peer_widx = ntb_peer_highest_mw_idx(ntb, i);
> + if (peer_widx < 0)
> + return peer_widx;
> +
> + ret = ntb_mw_get_trans_group(ntb, i, peer_widx, &first,
> + &count);
> + if (ret)
> + return ret;
> + if (first != peer_widx || count != 1)
> + return -EOPNOTSUPP;
> + }
> + }
> +
> ntb->msi = devm_kzalloc(&ntb->dev, struct_size(ntb->msi, peer_mws, peers),
> GFP_KERNEL);
> if (!ntb->msi)
[Severity: High]
This is a pre-existing issue, but does this code properly prevent a negative
index from being passed to the hardware driver?
Further down in drivers/ntb/msi.c:ntb_msi_init():
for (i = 0; i < peers; i++) {
peer_widx = ntb_peer_mw_count(ntb) - 1 - i;
ret = ntb_peer_mw_get_addr(ntb, peer_widx, &mw_phys_addr,
&mw_size);
If the hardware exposes fewer outbound memory windows (ntb_peer_mw_count(ntb))
than there are peers (ntb_peer_port_count(ntb)), won't the subtraction
underflow and make peer_widx negative?
Hardware drivers might fail to validate this negative index, resulting in
out-of-bounds array accesses and likely causing a kernel panic during device
probe.
[Severity: High]
This is also a pre-existing issue, but does the error handling in
ntb_msi_setup_mws() clear the correct memory window index on rollback?
In drivers/ntb/msi.c:ntb_msi_setup_mws():
error_out:
for (i = 0; i < peer; i++) {
peer_widx = ntb_peer_highest_mw_idx(ntb, peer);
if (peer_widx < 0)
continue;
ntb_mw_clear_trans(ntb, i, peer_widx);
}
The unroll loop queries ntb_peer_highest_mw_idx(ntb, peer) using the failing
peer index instead of the loop iterator i.
If peers have different memory window counts or indices, won't this leave an
active memory window mapping on the NTB hardware for previously configured
peers, or potentially clear the wrong window?
If the driver later reuses the uncleared memory window for regular data
transfers, remote memory writes could be interpreted as MSIs, leading to
hardware state corruption and spurious interrupts.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803180439.1963864-1-den@valinux.co.jp?part=9
next prev parent reply other threads:[~2026-08-03 18:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 18:04 [PATCH 00/11] PCI/NTB: endpoint: packed vNTB memory windows Koichiro Den
2026-08-03 18:04 ` [PATCH 01/11] NTB: Add atomic MW translation group operations Koichiro Den
2026-08-03 18:10 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 02/11] NTB: epf: Parse a versioned packed MW layout Koichiro Den
2026-08-03 18:23 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 03/11] PCI: endpoint: pci-epf-vntb: Add packed MW layout handling Koichiro Den
2026-08-03 18:25 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 04/11] PCI: endpoint: pci-epf-vntb: Implement MW group translation callbacks Koichiro Den
2026-08-03 18:25 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 05/11] PCI: endpoint: pci-epf-vntb: Allocate packed outbound MW space Koichiro Den
2026-08-03 18:32 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 06/11] PCI: endpoint: pci-epf-vntb: Add outbound MW group commands Koichiro Den
2026-08-03 18:28 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 07/11] NTB: epf: Implement MW group translation callbacks Koichiro Den
2026-08-03 18:29 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 08/11] NTB: perf: Reject grouped memory windows Koichiro Den
2026-08-03 18:25 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 09/11] NTB/msi: Require a singleton memory window Koichiro Den
2026-08-03 18:23 ` sashiko-bot [this message]
2026-08-03 18:04 ` [PATCH 10/11] NTB: ntb_transport: Use atomic MW translation groups Koichiro Den
2026-08-03 18:40 ` sashiko-bot
2026-08-03 18:04 ` [PATCH 11/11] PCI: endpoint: pci-epf-vntb: Expose packed MWs through configfs Koichiro Den
2026-08-03 18:40 ` sashiko-bot
2026-08-03 23:00 ` [PATCH 00/11] PCI/NTB: endpoint: packed vNTB memory windows Randy Dunlap
2026-08-04 0:55 ` 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=20260803182323.4E5901F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox