On Tue, Oct 06, 2026 at 06:11:36PM +0900, sungbyeongchan wrote: > Hello, > > I found a stale heap information disclosure in the SCSI VPD cache path > when a virtio-scsi backend completes a short data-in response as > successful. > > The backend first declares a 256-byte VPD page, then writes only the > four-byte VPD header. virtscsi_vq_done() obtains the used length from > virtqueue_get_buf(), but that length is not propagated to > virtscsi_complete_cmd(). With good status and resid=0, the SCSI core > accepts the device-declared page size. scsi_get_vpd_buf() allocates the > cache with kmalloc(), and the mode-0444 vpd_pg80 sysfs attribute later > copies the unwritten tail to an unprivileged reader. > > I reproduced this twice on commit > ff47652a4b66c067c765a7ad464d930b5a9367cc with a local > vhost-user-scsi backend. In both runs, uid 65534 read 252 stale bytes > from a reused same-size heap object after the four valid VPD bytes. A > normal full response returned only its valid data. Reporting the short > transfer through resid prevented the stale marker from being returned. > > The demonstrated impact is a bounded guest-kernel heap disclosure to an > unprivileged sysfs reader. I did not demonstrate arbitrary read/write, > code execution, host compromise, guest escape, or privilege escalation. > > As a minimal disclosure mitigation I tested changing the cached VPD > allocation to kzalloc(). The malicious fixed A/B returned a zero tail, > and the normal VPD control was unchanged. This mitigation prevents the > disclosure but does not make virtio-scsi reject every inconsistent > used-length/residual pair; maintainers may prefer to propagate and > validate the actual transfer length instead. > > I performed a best-effort public duplicate search through 2026-10-06 > and found no exact public report for this short virtio-scsi VPD response > and sysfs disclosure path. > > This report was prepared with AI assistance and is being treated as > public under Documentation/process/security-bugs.rst. A tested source > reproducer, backend, logs, configuration, and proposed mitigation are > available to the maintainers on request; the reproducer is intentionally > not attached to this public report. > > Assisted-by: LLM > > Regards, > sungbyeongchan
So a broken device makes guest kernel leak some uninitialized heap data to guest userspace? Is that a fair summary? -- MST
