* Re: [PATCH] ntb: fix typo "atleast" in comments
2026-09-04 11:55 [PATCH] ntb: fix typo "atleast" in comments Hemanth Selam
@ 2026-09-04 12:11 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-09-04 12:11 UTC (permalink / raw)
To: Hemanth Selam; +Cc: ntb
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but missing bounds validation of transport MTU and memory window sizes leads to division by zero or memory corruption.
- [High] This problem wasn't introduced by this patch, but an ignored error return from queue setup leaves queues in an uninitialized state, leading to memory corruption.
--
commit 33255de034b5213460a8b9b93908f62b983e3d06
Author: Hemanth Selam <hemanth.selam@gmail.com>
ntb: fix typo "atleast" in comments
Correct "atleast" to "at least", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index f59f926d4bfaa..f64e65b1d9019 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -611,7 +611,7 @@ static int ntb_transport_setup_qp_mw(struct ntb_transport_ctx *nt,
>
> qp->remote_rx_info = qp->rx_buff + rx_size;
>
> - /* Due to housekeeping, there must be atleast 2 buffs */
> + /* Due to housekeeping, there must be at least 2 buffs */
> qp->rx_max_frame = min(transport_mtu, rx_size / 2);
> qp->rx_max_entry = rx_size / qp->rx_max_frame;
[Severity: High]
This isn't a regression introduced by this patch, but missing bounds
validation of transport MTU and memory window sizes leads to division by zero
or memory corruption here.
If the remote peer configures a memory window size smaller than
sizeof(struct ntb_rx_info), subtracting this from the unsigned rx_size (just
before this block) causes an integer underflow, leading to wild out-of-bounds
pointer arithmetic.
Additionally, if the transport_mtu module parameter is set to 0, or if
rx_size / 2 is 0, qp->rx_max_frame becomes 0. Does this cause a division
by zero kernel panic on the very next line?
[Severity: High]
This is a pre-existing issue, but does ntb_transport_link_work() ignore the
-ENOMEM error returned later in this function?
ntb_transport_setup_qp_mw() allocates queue entries and returns -ENOMEM on
failure, skipping important state resets like setting
qp->remote_rx_info->entry and zeroing payload headers in qp->rx_buff.
It appears the caller, ntb_transport_link_work(), unconditionally ignores
this return value and activates the queue:
ntb_transport_link_work() {
...
ntb_transport_setup_qp_mw(nt, i);
ntb_transport_setup_qp_peer_msi(nt, i);
if (qp->client_ready)
schedule_delayed_work(&qp->link_work, 0);
...
}
Could this result in ntb_transport_rxc_db() processing uninitialized memory
as payload headers and performing an out-of-bounds memcpy in ntb_memcpy_rx()?
> qp->rx_index = 0;
> @@ -1195,7 +1195,7 @@ static int ntb_transport_init_queue(struct ntb_transport_ctx *nt,
> tx_size -= sizeof(struct ntb_rx_info);
> qp->rx_info = qp->tx_mw + tx_size;
>
> - /* Due to housekeeping, there must be atleast 2 buffs */
> + /* Due to housekeeping, there must be at least 2 buffs */
> qp->tx_max_frame = min(transport_mtu, tx_size / 2);
> qp->tx_max_entry = tx_size / qp->tx_max_frame;
[Severity: High]
This is a pre-existing issue, but identical vulnerabilities exist on the
transmit queue setup path.
If tx_size is smaller than sizeof(struct ntb_rx_info), does it underflow?
And if transport_mtu or tx_size / 2 is 0, does this result in a division by
zero kernel panic when calculating qp->tx_max_entry?
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904115534.11165-1-hemanth.selam@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread