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: 4+ 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
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 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.