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
next prev parent 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