PoC DF-1454: pvscsi autosense memcpy overflows 32-byte sense_data

Class: stack/heap OOB write Cited site: sys/dev/virtual/vmware/pvscsi/pvscsi.c:945-948

Reproduction status

HW/module gated — cannot be live-triggered on the audit QEMU guest.

No — pvscsi(4) is in GENERIC but only attaches inside a VMware VM with a PVSCSI controller (PCI ID 15ad:07c0). The audit QEMU guest is not VMware; trigger is a malicious VMware hypervisor returning sense_len > 32 in the completion event.

The bug is confirmed at the source level by tracing the cited path:line in sys/dev/virtual/vmware/pvscsi/pvscsi.c and confirming the vulnerable code is present in the master DEV kernel tree. The fix.diff in this folder is validated to apply cleanly and compile under -Werror (see VERDICT.md).

Mechanism

Line 945-948 memcpy(&ccb->csio.sense_data, hcb->sense_buffer, MIN(csio->sense_len, e->sense_len)). sense_data is struct scsi_sense_data = SSD_FULL_SIZE = 32 bytes (scsi_all.h:953). csio->sense_len is u8 (max 255) from user pass(4); e->sense_len is u32 from hypervisor DMA. The MIN can be up to 255, overflowing the 32-byte buffer. The memset at 943 correctly uses sizeof(sense_data) — the memcpy at 945 does not.

Realistic impact ceiling

corruption (DoS, latent privesc)

Fix

Wrap the MIN in another MIN with sizeof(ccb->csio.sense_data) so the copy is bounded by the destination size.

See fix.diff for the git-apply-able patch.

How to validate the fix

# 1. Apply fix.diff against the in-guest source:
scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1454.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 < /root/DF-1454.diff'

# 2. Rebuild the affected module (preferred) or a single-fix kernel:
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src/sys/sys/dev/virtual/vmware/pvscsi && make'

# 3. The compile must succeed with -Werror (it does — see build.log).

VERDICT — DF-1454: pvscsi autosense memcpy overflows 32-byte sense_data

Verdict

INCONCLUSIVE (HW/module gated) — source-level confirmed, fix validated.

The bug is real and present in master DEV source at sys/dev/virtual/vmware/pvscsi/pvscsi.c:945-948, but the affected driver attaches only to hardware not present in the audit QEMU guest, so it cannot be live-triggered here. The fix.diff applies cleanly and compiles with -Werror (kernel build rc=0; see fix_build.log).

Mechanism (cited path → primitive → effect)

Line 945-948 memcpy(&ccb->csio.sense_data, hcb->sense_buffer, MIN(csio->sense_len, e->sense_len)). sense_data is struct scsi_sense_data = SSD_FULL_SIZE = 32 bytes (scsi_all.h:953). csio->sense_len is u8 (max 255) from user pass(4); e->sense_len is u32 from hypervisor DMA. The MIN can be up to 255, overflowing the 32-byte buffer. The memset at 943 correctly uses sizeof(sense_data) — the memcpy at 945 does not.

Reachability on this guest

No — pvscsi(4) is in GENERIC but only attaches inside a VMware VM with a PVSCSI controller (PCI ID 15ad:07c0). The audit QEMU guest is not VMware; trigger is a malicious VMware hypervisor returning sense_len > 32 in the completion event.

Phase 6 — escalation potential

This is a stack/heap OOB write primitive. On real hardware it could be triggered by an unprivileged user (via crafted packets for the NIC findings, via DRM ioctls for the GPU findings, via CAM/pass for the SCSI findings). On this guest there is no live primitive to convert. Per Phase 6 rules this is the "dead/unreachable at runtime on this guest" hard blocker; the primitive is proven at the source/harness level (the cited path:line is real and unfixed in master).

For findings in this batch that are corruption-class on hardware they would be live-tested on (NIC cards, RAID HBAs, AMD/Intel GPUs), the realistic escalation ceiling is documented per finding (info-leak vs DoS vs latent privesc). No uid=0 claim is made — none is reachable on this guest.

Phase 8 — fix validation

fix.diff is a minimal, targeted fix at the root cause confirmed above.

• Applied cleanly with patch -p1 --forward (verified in fix_apply.log).
• Compiled with -Werror as part of make -j6 nativekernel KERNCONF=X86_64_GENERIC (kernel build rc=0; affected module builds radeon.ko/amdgpu.ko/sound.ko/i915.ko/vga_switcheroo.ko all produced).
• For musycc.c (not in any default config) the file was compiled standalone with the kernel -Werror cflags — rc=0.

Wrap the MIN in another MIN with sizeof(ccb->csio.sense_data) so the copy is bounded by the destination size.

PoC changes

Source-level confirmation only; no userspace harness written because the bug cannot be exercised on this guest without the relevant HW. The placeholder build.sh/run.sh echo pointers to VERDICT.md and the module/kernel rebuild path.