Re: [PATCH net v3] net/smc: fix out-of-bounds read of rkey array in SMC-Rv2 LLC processing

[sashiko-bot@kernel.org]

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

New issues:
- [High] Accessing the flexible array member `rkey` in `smc_llc_rmt_delete_rkey` crosses the statically known boundary of the `msg` union into the `body` flexible array, triggering a compiler array-bounds panic.

Pre-existing issues:
- [High] The function `smc_rtoken_delete` modifies shared rtoken state without holding the appropriate lock, leading to a race condition.
--

--- Patch [1]: [PATCH net v3] net/smc: fix out-of-bounds read of rkey array in SMC-Rv2 LLC processing ---
commit bc4e86ac0d674a2bb992c13bb4936670fa839d8d
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

net/smc: fix out-of-bounds read of rkey array in SMC-Rv2 LLC processing

This commit fixes an out-of-bounds read when processing SMC-Rv2 messages
in non-shared link scenarios. It changes smc_llc_qentry to carry the
message body in a flexible array rather than relying on a separate buffer.
Loop bounds are also clamped to the received byte length.

> diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
> index 954b2ff1815c2..997664bbe4f2a 100644
> --- a/net/smc/smc_llc.c
> +++ b/net/smc/smc_llc.c

[ ... ]

> @@ -1811,16 +1819,15 @@ static void smc_llc_rmt_delete_rkey(struct smc_link_group *lgr)
>  
>  	if (lgr->smc_version == SMC_V2) {
>  		struct smc_llc_msg_delete_rkey_v2 *llcv2;
> +		const u32 rkey_off =
> +			offsetof(struct smc_llc_msg_delete_rkey_v2, rkey);
>  
> -		if (smc_link_shared_v2_rxbuf(link)) {
> -			memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc));
> -			llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2;
> -		} else {
> -			llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)llc;
> -		}
> +		llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)llc;
>  		llcv2->num_inval_rkeys = 0;
>  
>  		max = min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
> +		max = min_t(u32, max, (sizeof(qentry->msg) + qentry->body_len -
> +				       rkey_off) / sizeof(llcv2->rkey[0]));
>  		for (i = 0; i < max; i++) {
>  			if (smc_rtoken_delete(link, llcv2->rkey[i]))

[Severity: High]
Will this trigger a UBSAN array-bounds panic for large messages?

Since llcv2 is cast from the 44-byte msg union, but the rkeys actually
extend into the adjacent qentry->body flexible array, doesn't reading
llcv2->rkey[i] for i >= 9 cross the statically known boundaries of the
union?

Even though the memory is physically contiguous, accessing beyond the union
size violates strict intra-object bounds checking.

[Severity: High]
This is a pre-existing issue, but does this loop need locking to protect
against concurrent modifications to the rtoken structures?

When smc_llc_rmt_delete_rkey() calls smc_rtoken_delete() to modify
lgr->rtokens and lgr->rtokens_used_mask, neither lgr->rmbs_lock nor
lgr->llc_conf_mutex is held.

Since smc_llc_save_add_link_rkeys() and smcr_rtoken_clear_link() can run
concurrently and modify these same structures, could this result in data
corruption of the RDMA memory access keys?

>  				llcv2->num_inval_rkeys++;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727095833.1079618-1-yhlee@isslab.korea.ac.kr?part=1