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

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

[sungbyeongchan]

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

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

[Michael S. Tsirkin]

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

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

[성병찬]

Yes, that is a fair summary.

More precisely, a short successful virtio-scsi response causes the
guest kernel to cache bytes that were not supplied by the device and
expose them through the world-readable VPD sysfs attribute.

The guest-kernel heap disclosure is reproducible. I agree that its
security classification depends on whether the virtio-scsi
device/backend is considered trusted in the relevant threat model.

Would validating and propagating the actual virtqueue used length be
worthwhile as a robustness fix?

Regards,
sungbyeongchan

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

[Michael S. Tsirkin]

On Tue, Oct 06, 2026 at 06:40:54PM +0900, 성병찬 wrote:
> Yes, that is a fair summary.
> 
> More precisely, a short successful virtio-scsi response causes the
> guest kernel to cache bytes that were not supplied by the device and
> expose them through the world-readable VPD sysfs attribute.
> 
> The guest-kernel heap disclosure is reproducible. I agree that its
> security classification depends on whether the virtio-scsi
> device/backend is considered trusted in the relevant threat model.
> 
> Would validating and propagating the actual virtqueue used length be
> worthwhile as a robustness fix?
> 
> Regards,
> sungbyeongchan
> 

I think so but please copy all relevant maintainers.

 ./scripts/get_maintainer.pl -f drivers/scsi/virtio_scsi.c
"Michael S. Tsirkin" <mst@redhat.com> (maintainer:VIRTIO BLOCK AND SCSI DRIVERS)
Jason Wang <jasowangio@gmail.com> (maintainer:VIRTIO BLOCK AND SCSI DRIVERS)
Paolo Bonzini <pbonzini@redhat.com> (reviewer:VIRTIO BLOCK AND SCSI DRIVERS)
Stefan Hajnoczi <stefanha@redhat.com> (reviewer:VIRTIO BLOCK AND SCSI DRIVERS)
"Eugenio Pérez" <eperezma@redhat.com> (reviewer:VIRTIO BLOCK AND SCSI DRIVERS)
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> (maintainer:SCSI SUBSYSTEM)
"Martin K. Petersen" <mkp@kernel.org> (maintainer:SCSI SUBSYSTEM)
virtualization@lists.linux.dev (open list:VIRTIO BLOCK AND SCSI DRIVERS)
linux-scsi@vger.kernel.org (open list:SCSI SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)


-- 
MST