Linux PCI subsystem development
 help / color / mirror / Atom feed
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

  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