Re: [BUG] scsi: short virtio-scsi VPD response exposes stale heap data

["Michael S. Tsirkin" <mst@redhat.com>]

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