[PATCH 0/3] scsi: ufs: Fix UIC result byte and BSG request length handling

[PATCH 0/3] scsi: ufs: Fix UIC result byte and BSG request length handling

[Stanley Jhu]

Two ufs-bsg fixes for issues found by fuzzing /dev/bsg/ufs-bsg* with
syzkaller on QEMU's emulated UFS host controller, plus a related fix
for the same UIC result byte problem in the peer DME retry path.

Patch 1 rejects requests shorter than the UFS BSG request structures.
Patch 2 clears the UIC result byte supplied by userspace.
Patch 3 clears the stale UIC result byte before peer DME retries.

Tested on QEMU arm64: the reproducers no longer trigger.

Stanley Jhu (3):
  scsi: ufs: bsg: Validate request_len before accessing request
  scsi: ufs: bsg: Clear the UIC result byte before sending UIC commands
  scsi: ufs: core: Clear stale UIC result byte before peer DME retries

 drivers/ufs/core/ufs_bsg.c | 9 +++++++++
 drivers/ufs/core/ufshcd.c  | 2 ++
 2 files changed, 11 insertions(+)

-- 
2.56.0.385.gd3acb90ef8-goog

[PATCH 1/3] scsi: ufs: bsg: Validate request_len before accessing request

[Stanley Jhu]

ufs_bsg_request() and ufs_bsg_exec_advanced_rpmb_req() read the
request buffer without checking job->request_len, which userspace
controls. A short request causes an out-of-bounds read. Found by
syzkaller.

Reject requests shorter than the structure each path reads.

Fixes: 64d4864714c2 ("scsi: ufs: bsg: Remove unnecessary length checkup")
Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
---
 drivers/ufs/core/ufs_bsg.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/ufs/core/ufs_bsg.c b/drivers/ufs/core/ufs_bsg.c
index 7a66917b3fc0..dab1f05aff38 100644
--- a/drivers/ufs/core/ufs_bsg.c
+++ b/drivers/ufs/core/ufs_bsg.c
@@ -73,6 +73,9 @@ static int ufs_bsg_exec_advanced_rpmb_req(struct ufs_hba *hba, struct bsg_job *j
 	if (hba->ufs_version < ufshci_version(4, 0) || !hba->dev_info.b_advanced_rpmb_en)
 		return -EINVAL;
 
+	if (job->request_len < sizeof(*rpmb_request))
+		return -EINVAL;
+
 	if (rpmb_request->ehs_req.length != 2 || rpmb_request->ehs_req.ehs_type != 1)
 		return -EINVAL;
 
@@ -142,6 +145,11 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
+	if (job->request_len < sizeof(*bsg_request)) {
+		bsg_reply->result = -EINVAL;
+		return -EINVAL;
+	}
+
 	ufshcd_rpm_get_sync(hba);
 
 	msgcode = bsg_request->msgcode;
-- 
2.56.0.385.gd3acb90ef8-goog

Re: [PATCH 1/3] scsi: ufs: bsg: Validate request_len before accessing request

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ufs/bsg: heap buffer overflow in Advanced RPMB reply handling
- [Medium] block: memory and device refcount leak on ufs_bsg_request() error path
--

commit 6c7ab99a857f0be8f1f19eb78aa230d8ccb39b14
Author: Stanley Jhu <stanleyjhu@google.com>

scsi: ufs: bsg: Validate request_len before accessing request

This commit adds validation checks for job->request_len in the UFS
BSG paths to prevent out-of-bounds reads when userspace provides
short requests.

> diff --git a/drivers/ufs/core/ufs_bsg.c b/drivers/ufs/core/ufs_bsg.c
> index 7a66917b3fc0e..dab1f05aff383 100644
> --- a/drivers/ufs/core/ufs_bsg.c
> +++ b/drivers/ufs/core/ufs_bsg.c
> @@ -73,6 +73,9 @@ static int ufs_bsg_exec_advanced_rpmb_req(struct ufs_hba *hba, struct bsg_job *j
>  	if (hba->ufs_version < ufshci_version(4, 0) || !hba->dev_info.b_advanced_rpmb_en)
>  		return -EINVAL;
>  
> +	if (job->request_len < sizeof(*rpmb_request))
> +		return -EINVAL;
> +

[Severity: High]
While this properly validates the request size, does the reply handling
contain a heap buffer overflow for advanced RPMB requests?

The BSG core allocates job->reply in bsg_init_rq() with a fixed size of
SCSI_SENSE_BUFFERSIZE (96 bytes). However, ufs_bsg_exec_advanced_rpmb_req()
casts job->reply to struct ufs_rpmb_reply, which has a size of 104 bytes:
sizeof(struct ufs_bsg_reply) (40 bytes) + sizeof(struct ufs_ehs) (64 bytes).

When ufshcd_advanced_rpmb_req_handler() is called, it writes 64 bytes
to the ehs_rsp field at offset 40, resulting in an 8-byte out-of-bounds
write on the heap:

drivers/ufs/core/ufshcd.c:ufshcd_advanced_rpmb_req_handler() {
    ...
    memcpy(rsp_ehs, ehs_data, ehs_len * 32);
    ...
}

Later, ufs_bsg_request() sets job->reply_len to 104 for RPMB replies,
which configures the block layer to copy 104 bytes to user space from
this 96-byte allocation. Will this leak adjacent heap memory to userspace?

[ ... ]

> @@ -142,6 +145,11 @@ static int ufs_bsg_request(struct bsg_job *job)
>  
>  	bsg_reply->reply_payload_rcv_len = 0;
>  
> +	if (job->request_len < sizeof(*bsg_request)) {
> +		bsg_reply->result = -EINVAL;
> +		return -EINVAL;
> +	}
> +

[Severity: Medium]
Does returning -EINVAL directly bypass the BSG job completion mechanism
and permanently leak the job's resources?

When ufs_bsg_request() returns -EINVAL directly, the block layer's
bsg_queue_rq() returns BLK_STS_IOERR. This causes blk_mq_end_request()
to complete the request without invoking the queue's .complete callback
(bsg_complete()).

Because bsg_complete() is bypassed, bsg_job_put() is never called,
meaning bsg_teardown_job() never executes. This leaves the sg_list
memory and the job->dev reference count permanently leaked, which would
prevent the UFS device from ever being cleanly removed.

Should this error path instead call bsg_job_done(job, -EINVAL, 0)
and return 0 to ensure proper teardown?

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

[PATCH 2/3] scsi: ufs: bsg: Clear the UIC result byte before sending UIC commands

[Stanley Jhu]

ufs_bsg_request() passes the user-supplied UIC argument2 unchanged,
including the result byte (bits 7:0) that only the host controller
writes. A non-zero value triggers the WARN_ON_ONCE() in
ufshcd_dispatch_uic_cmd() and corrupts the reported result. Found by
syzkaller.

Clear the result byte before sending the command.

Fixes: e77044c5a842 ("scsi: ufs-bsg: Add support for uic commands in ufs_bsg_request()")
Fixes: 9fb4c793223b ("scsi: ufs: core: Complain if UIC argument 2 is invalid")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
---
 drivers/ufs/core/ufs_bsg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ufs/core/ufs_bsg.c b/drivers/ufs/core/ufs_bsg.c
index dab1f05aff38..331ead0403a1 100644
--- a/drivers/ufs/core/ufs_bsg.c
+++ b/drivers/ufs/core/ufs_bsg.c
@@ -179,6 +179,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	case UPIU_TRANSACTION_UIC_CMD:
 		memcpy(&uc, &bsg_request->upiu_req.uc, UIC_CMD_SIZE);
+		uc.argument2 &= ~MASK_UIC_COMMAND_RESULT;
 		ret = ufshcd_send_bsg_uic_cmd(hba, &uc);
 		if (ret)
 			dev_err(hba->dev, "send uic cmd: error code %d\n", ret);
-- 
2.56.0.385.gd3acb90ef8-goog

[PATCH 3/3] scsi: ufs: core: Clear stale UIC result byte before peer DME retries

[Stanley Jhu]

Peer DME get and set retry a failed attempt with the same struct
uic_command. UIC completion ORs the ConfigResultCode into
argument2[7:0], and nothing clears it before the next attempt. Once an
attempt fails, every retry keeps reporting that error code, even when
the device returns success, so a transient failure becomes a hard
failure after three retries. Each such retry also triggers the
WARN_ON_ONCE() in ufshcd_dispatch_uic_cmd().

Clear the result byte before each attempt.

Fixes: 64238fbd15ea ("scsi: ufs: add retries to dme_peer get and set attribute")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
---
 drivers/ufs/core/ufshcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index bcc2512bf34b..9adb3b576e28 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -4398,6 +4398,7 @@ int ufshcd_dme_set_attr(struct ufs_hba *hba, u32 attr_sel,
 	int retries = UFS_UIC_COMMAND_RETRIES;
 
 	do {
+		uic_cmd.argument2 &= ~MASK_UIC_COMMAND_RESULT;
 		/* for peer attributes we retry upon failure */
 		ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
 		if (ret)
@@ -4465,6 +4466,7 @@ int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
 	}
 
 	do {
+		uic_cmd.argument2 &= ~MASK_UIC_COMMAND_RESULT;
 		/* for peer attributes we retry upon failure */
 		ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
 		if (ret)
-- 
2.56.0.385.gd3acb90ef8-goog

Re: [PATCH 3/3] scsi: ufs: core: Clear stale UIC result byte before peer DME retries

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: ufs: dme_set retry loop reuses potentially corrupted argument3
--

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

scsi: ufs: core: Clear stale UIC result byte before peer DME retries

Peer DME get and set retry a failed attempt with the same struct
uic_command. This commit clears the result byte in argument2 before
each attempt to prevent transient failures from becoming hard failures
due to stale error codes.

Fixes: 64238fbd15ea ("scsi: ufs: add retries to dme_peer get and set attribute")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index cc75384c65021..1f254402d3b4b 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -4398,6 +4398,7 @@ int ufshcd_dme_set_attr(struct ufs_hba *hba, u32 attr_sel,
>  	int retries = UFS_UIC_COMMAND_RETRIES;
>  
>  	do {
> +		uic_cmd.argument2 &= ~MASK_UIC_COMMAND_RESULT;

[Severity: Medium]
When ufshcd_send_uic_cmd() fails, does the completion handler overwrite
argument3?

Looking at ufshcd_uic_cmd_compl(), it appears argument3 is unconditionally
updated with the hardware register's contents:

ufshcd_uic_cmd_compl() {
	...
	/* Store the DME attribute value in cmd->argument3. */
	cmd->argument3 = ufshcd_readl(hba, REG_UIC_COMMAND_ARG_3);
	...
}

Since uic_cmd.argument3 is initialized to mib_val only once outside the
retry loop in ufshcd_dme_set_attr(), can this regression cause a subsequent
retry to write whatever value the hardware left in the register during the
failure?

Should uic_cmd.argument3 be restored to mib_val before retrying, similar
to how argument2 is cleared here?

>  		/* for peer attributes we retry upon failure */
>  		ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
>  		if (ret)

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

Re: [PATCH 3/3] scsi: ufs: core: Clear stale UIC result byte before peer DME retries

[Stanley Jhu]

On Tue, Oct 13, 2026 at 10:41:55AM +0000, sashiko-bot@kernel.org wrote:
> Since uic_cmd.argument3 is initialized to mib_val only once outside the
> retry loop in ufshcd_dme_set_attr(), can this regression cause a  
> subsequent
> retry to write whatever value the hardware left in the register during the
> failure?

> Should uic_cmd.argument3 be restored to mib_val before retrying, similar
> to how argument2 is cleared here?

Good point. ufshcd_uic_cmd_compl() always overwrites argument3, so
the DME_SET retry should restore mib_val as well. I'll fold that into
v2.