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

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 971199ad2a0f Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1415792f980000
kernel config: https://syzkaller.appspot.com/x/.config?x=ed013bd3465f2abf
dashboard link: https://syzkaller.appspot.com/bug?extid=a7b56f5926d90eaf5071
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/32974b5d3b23/disk-971199ad.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3850d8c7dc24/vmlinux-971199ad.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6ab0a4c5a862/bzImage-971199ad.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a7b56f...@syzkaller.appspotmail.com

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

Uninit was created at:
__alloc_frozen_pages_noprof+0x689/0xf00 mm/page_alloc.c:5206
alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2416
alloc_frozen_pages_noprof+0xf7/0x200 mm/mempolicy.c:2487
alloc_slab_page mm/slub.c:3030 [inline]
allocate_slab+0x26c/0x14e0 mm/slub.c:3203
new_slab mm/slub.c:3257 [inline]
___slab_alloc+0x131b/0x3d90 mm/slub.c:4627
__slab_alloc+0xa3/0x180 mm/slub.c:4746
__slab_alloc_node mm/slub.c:4822 [inline]
slab_alloc_node mm/slub.c:5233 [inline]
__do_kmalloc_node mm/slub.c:5602 [inline]
__kmalloc_noprof+0xba3/0x1b40 mm/slub.c:5615
kmalloc_noprof include/linux/slab.h:961 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
lsm_blob_alloc security/security.c:690 [inline]
lsm_task_alloc security/security.c:777 [inline]
security_task_alloc+0xa1/0x6b0 security/security.c:3229
copy_process+0x235a/0x5eb0 kernel/fork.c:2163
kernel_clone+0x416/0x1080 kernel/fork.c:2609
user_mode_thread+0xde/0x110 kernel/fork.c:2685
call_usermodehelper_exec_work+0x8a/0x300 kernel/umh.c:171
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

CPU: 1 UID: 0 PID: 58 Comm: kworker/u8:3 Not tainted syzkaller #0 PREEMPT(none)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
Workqueue: async async_run_entry_fn
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Bart Van Assche]

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.