Re: [PATCH] scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies
From: Stanley Jhu
Date: Wed Oct 14 2026 - 20:20:19 EST
On Tue, Oct 13, 2026 at 01:39:40PM +0000, sashiko-bot@xxxxxxxxxx wrote:
> Since job->result is 0, this check is bypassed and the full bset->reply_len
> bytes of the uninitialized or recycled job->reply buffer will be copied to
> user space. For UFS Advanced RPMB, this could leak up to 104 bytes of the
> previous request's data.
>
> Should the reply buffer be cleared when initializing the job, or should
> job->result be explicitly set on all error paths?
This is pre-existing in ufs_bsg_request() and not tied to the new reply
length; the same happens today with the 96-byte buffer. The other BSG
transports complete the job via bsg_job_done() on error.
Both points are fixed in the UFS BSG series v2:
- 1/5 completes failed jobs via bsg_job_done(), so job->result carries
the error.
- 2/5 clears the reply buffer on entry to ufs_bsg_request().
https://lore.kernel.org/all/20261015001855.3450573-1-stanleyjhu@xxxxxxxxxx/