Re: [PATCH v2 2/5] scsi: ufs: bsg: Clear the reply buffer before use

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ufs: heap overflow in ufs_bsg_exec_advanced_rpmb_req()
--

commit 8509b25f617ae6bb6b7c915900b84d8957279281
Author: Stanley Jhu <stanleyjhu@google.com>

scsi: ufs: bsg: Clear the reply buffer before use

This commit clears the bsg job reply buffer upon entry to ufs_bsg_request()
to prevent leaking bytes from an earlier request on the same tag. It
replaces a targeted zeroing of the length field with a memset of the entire
buffer.

> diff --git a/drivers/ufs/core/ufs_bsg.c b/drivers/ufs/core/ufs_bsg.c
> index 18c318d781224..545ef7b79ceb5 100644
> --- a/drivers/ufs/core/ufs_bsg.c
> +++ b/drivers/ufs/core/ufs_bsg.c
> @@ -140,7 +140,7 @@ static int ufs_bsg_request(struct bsg_job *job)
>  	int ret;
>  	bool rpmb = false;
>  
> -	bsg_reply->reply_payload_rcv_len = 0;
> +	memset(job->reply, 0, job->reply_len);

[Severity: High]
Does this regression still allow a heap buffer overflow when processing
Advanced RPMB requests?

While the memset safely clears the 96 bytes initialized by bsg_init_rq()
in block/bsg-lib.c, the subsequent handling in
ufs_bsg_exec_advanced_rpmb_req() in drivers/ufs/core/ufs_bsg.c casts this
96-byte buffer to a struct ufs_rpmb_reply, which is 104 bytes in size.

When ufshcd_advanced_rpmb_req_handler() in drivers/ufs/core/ufshcd.c
handles the response, it executes:

memcpy(rsp_ehs, ehs_data, ehs_len * 32);

Will this copy write 64 bytes starting at offset 40, exceeding the 96-byte
allocation by 8 bytes and corrupting out-of-bounds memory?

>  
>  	ufshcd_rpm_get_sync(hba);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015001855.3450573-1-stanleyjhu@google.com?part=2