Re: [PATCH v9 05/11] scsi: sr: retry unfinished media revalidation on the next open

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: sr: uninitialized stack memory read of sshdr in sr_revalidate_disk()
--

commit 6831e2d4751ec5b84e9b7b08a5e93e7b6123ef75
Author: Phil Pemberton <philpem@philpem.me.uk>

scsi: sr: retry unfinished media revalidation on the next open

This commit updates the scsi sr driver to keep media revalidation pending
until it completes, handling cases where a new disc is still spinning up.
It introduces a mechanism to return -ENOMEDIUM for blocking opens if the
drive reports it is becoming ready, ensuring the queue limits update is
eventually completed.

[Severity: Medium]
Could the new check in sr_revalidate_disk() result in an uninitialized stack
memory read if the scsi command fails early?

In drivers/scsi/sr.c at line 485 within sr_revalidate_disk(), the code
evaluates scsi_sense_valid(&sshdr) and reads sshdr.sense_key, sshdr.asc,
and sshdr.ascq. However, sshdr is allocated on the stack without
zero-initialization.

If scsi_test_unit_ready() encounters an early failure (such as an allocation
failure in scsi_alloc_request() returning -ENOMEM or -ENXIO), it returns the
negative error code immediately without populating sshdr. Since the new logic
checks scsi_sense_valid() whenever scsi_test_unit_ready() returns non-zero,
it will read the uninitialized sshdr.response_code.

If the random stack data happens to match the 0x70 mask required by
scsi_sense_valid(), the code will further evaluate the uninitialized
sense_key, asc, and ascq fields. Can this cause unrelated errors to be
incorrectly masked as -ENOMEDIUM, or trigger KMSAN uninitialized memory
warnings?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006234202.1139018-1-philpem@philpem.me.uk?part=5