Re: [syzbot] [scsi?] upstream test error: KMSAN: uninit-value in scsi_get_vpd_buf

[Bart Van Assche <bvanassche@acm.org>]

On 10/8/25 12:52 PM, syzbot wrote:
> scsi 0:0:1:0: Direct-Access     Google   PersistentDisk   1    PQ: 0 ANSI: 6
> =====================================================
> BUG: KMSAN: uninit-value in scsi_vpd_inquiry drivers/scsi/scsi.c:323 [inline]
> BUG: KMSAN: uninit-value in scsi_get_vpd_buf+0x4cc/0x720 drivers/scsi/scsi.c:455
>   scsi_vpd_inquiry drivers/scsi/scsi.c:323 [inline]
>   scsi_get_vpd_buf+0x4cc/0x720 drivers/scsi/scsi.c:455
>   scsi_update_vpd_page drivers/scsi/scsi.c:479 [inline]
>   scsi_attach_vpd+0x380/0xe70 drivers/scsi/scsi.c:520
>   scsi_add_lun drivers/scsi/scsi_scan.c:1110 [inline]
>   scsi_probe_and_add_lun+0x6933/0x7f20 drivers/scsi/scsi_scan.c:1288
>   __scsi_scan_target+0x2fb/0x2050 drivers/scsi/scsi_scan.c:1776
>   scsi_scan_channel drivers/scsi/scsi_scan.c:1864 [inline]
>   scsi_scan_host_selected+0x68f/0x9a0 drivers/scsi/scsi_scan.c:1893
>   do_scsi_scan_host drivers/scsi/scsi_scan.c:2032 [inline]
>   do_scan_async+0x1ad/0xdc0 drivers/scsi/scsi_scan.c:2042
>   async_run_entry_fn+0x90/0x570 kernel/async.c:129
>   process_one_work kernel/workqueue.c:3263 [inline]
>   process_scheduled_works+0xb91/0x1d80 kernel/workqueue.c:3346
>   worker_thread+0xedf/0x1590 kernel/workqueue.c:3427
>   kthread+0xd59/0xf00 kernel/kthread.c:463
>   ret_from_fork+0x233/0x380 arch/x86/kernel/process.c:158
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Syzkaller team, does the above output perhaps indicate that the 
implementation of one of the VPD pages in the Google Persistent Disk
product is not compliant with the SCSI standard? Although it would be
easy to suppress the above complaint by zero-initializing VPD buffers
before submitting an INQUIRY command, I think the above complaint
indicates that the response to an INQUIRY command is shorter than four
bytes. The SCSI SPC standard requires that INQUIRY responses are at
least four bytes long if the EVPD bit has been set.

Thanks,

Bart.