Re: [PATCH] ntb: fix typo "atleast" in comments

[sashiko-bot@kernel.org]

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