Linux PCI Non-Transparent Bridge framework and drivers
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: ntb@lists.linux.dev
Subject: Re: [PATCH net 1/2] net: ntb_netdev: Avoid double-accounting netif_rx() drops
Date: Thu, 20 Aug 2026 17:25:52 +0000	[thread overview]
Message-ID: <20260820172553.7009F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819172539.1450821-2-den@valinux.co.jp>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Time-of-Check to Time-of-Use (TOCTOU) vulnerability in NTB receive processing allows a malicious remote peer to cause a massive kernel heap buffer overflow.
--

--- Patch [1]: [PATCH net 1/2] net: ntb_netdev: Avoid double-accounting netif_rx() drops ---
commit 002045303db9fc237bf287acbb8f01a9873c837d
Author: Koichiro Den <den@valinux.co.jp>

net: ntb_netdev: Avoid double-accounting netif_rx() drops

netif_rx() already accounts packets it drops in the core rx_dropped
counter. ntb_netdev counts them again as both errors and drops.
Leave netif_rx() drops to the core. Count the packet and bytes
unconditionally since it was received successfully by the driver.

> diff --git a/drivers/net/ntb_netdev.c b/drivers/net/ntb_netdev.c
> index 029a4a532a104..4e53b00f016b0 100644
> --- a/drivers/net/ntb_netdev.c
> +++ b/drivers/net/ntb_netdev.c
> @@ -155,13 +155,9 @@ static void ntb_netdev_rx_handler(struct ntb_transport_qp *qp, void *qp_data,
>  	skb->ip_summed = CHECKSUM_NONE;
>  	skb_record_rx_queue(skb, q->qid);
>  
> -	if (netif_rx(skb) == NET_RX_DROP) {
> -		ndev->stats.rx_errors++;
> -		ndev->stats.rx_dropped++;
> -	} else {
> -		ndev->stats.rx_packets++;
> -		ndev->stats.rx_bytes += len;
> -	}
> +	netif_rx(skb);
> +	ndev->stats.rx_packets++;
> +	ndev->stats.rx_bytes += len;

[Severity: Critical]
This is a pre-existing issue, but does this expose a time-of-check to
time-of-use issue during ntb receive processing?

Looking at ntb_process_rxc() in drivers/ntb/ntb_transport.c, hdr directly
accesses the shared memory window which the remote peer can write to via
pcie. A bounds check is performed, but then hdr->len is re-read directly
from the shared memory:

drivers/ntb/ntb_transport.c:ntb_process_rxc() {
	if (hdr->len > entry->len) {
		...
	} else {
		...
		entry->len = hdr->len;

		ntb_async_rx(entry, offset);
	}
}

Can the remote peer modify hdr->len to a massive value after the bounds
check passes but before the second read?

If so, this bypassed length is then passed to ntb_async_rx() and
subsequently to ntb_memcpy_rx():

drivers/ntb/ntb_transport.c:ntb_memcpy_rx() {
	void *buf = entry->buf;
	size_t len = entry->len;

	memcpy(buf, offset, len);
}

Could this cause memcpy() to overflow the skb data buffer? Should the
payload header values be copied to local variables using READ_ONCE() before
validation to prevent this?

>  
>  	skb = new_skb;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819172539.1450821-1-den@valinux.co.jp?part=1

  reply	other threads:[~2026-08-20 17:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 17:25 [PATCH net 0/2] net: ntb_netdev: Fix RX statistics accounting Koichiro Den
2026-08-19 17:25 ` [PATCH net 1/2] net: ntb_netdev: Avoid double-accounting netif_rx() drops Koichiro Den
2026-08-20 17:25   ` sashiko-bot [this message]
2026-08-19 17:25 ` [PATCH net 2/2] net: ntb_netdev: Count packets dropped on RX refill failure Koichiro Den
2026-08-22 20:20 ` [PATCH net 0/2] net: ntb_netdev: Fix RX statistics accounting patchwork-bot+netdevbpf

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=20260820172553.7009F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=den@valinux.co.jp \
    --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