# CVE-2025-59516 — Windows Hyper-V Storage VSP `storvsp.sys` Missing Authentication

---

## Summary

| **Product** | Microsoft Windows — `storvsp.sys` (Hyper-V Storage VSP / VSMB miniport) |
|---|---|
| **Vendor** | Microsoft Corporation |
| **Severity** | CVSS v3.1 **8.8 (High)** |
| **CVE Title** | Windows Hyper-V Storage VSP Elevation of Privilege Vulnerability |
| **CWE** | CWE-306 (Missing Authentication for Critical Function), CWE-863 (Incorrect Authorization) |
| **Affected Versions** | Windows Server with Hyper-V role (VSMB enabled) |
| **Impact** | VM guest → host EoP — unauthenticated guest opens host `\Device` paths |
| **Exploited ITW** | No |
| **Patch Date** | December 2025 Patch Tuesday |
| **Public analysis** | [78 Research Lab — VSMB missing auth](https://blog.78researchlab.com/2ffdb461-3e5b-8066-8856-cd04baee34dc) |

---

## Root Cause

Hyper-V's **Virtual SMB (VSMB)** miniport (`storvsp.sys`) allows a guest VM to
perform file-system-like operations against the host through the
`\Device\STORVSP\VSMB` device. Two functions fail to authenticate the caller:

- **`VspVsmbFileCreate`** — handles `NtCreateFile` requests from the guest.
- **`VspVsmbCommonRelativeCreate`** — handles relative-path creates.

Neither function validates the calling VM's privilege level. The code:

1. Calls `ZwOpenDirectoryObject` directly on `\Device` paths without checking
   if the caller is authorized to access those paths.
2. In `VspVsmbGetStatInfo`, a **Flags bit** can bypass intended access checks,
   allowing the guest to open arbitrary host device objects.

### The patch (verified in ghidriff diff, 5074 → 7171)

The diff shows one key function changed:

- **`VspVsmbFileIoctlVstorVsmbOpenFileValidate`** (83% match) — removed the
  `Feature_2561731899__private_IsEnabledDeviceUsageNoInline` feature-gate checks
  and replaced them with **strict bounds validation** on the request buffer.
  The post-patch code validates every field offset and size against the request
  length before processing, preventing the auth bypass.

- **`VspIsValidSgRequest`** (61% match) — hardened scatter-gather request
  validation.

Diff: `ghidriff/CVE-2025-59516/output/storvsp-10.0.26100.5074.sys-storvsp-10.0.26100.7171.sys.ghidriff.md`

---

## Reaching the bug — VM guest call flow

Reachable from **inside any guest VM** communicating with the VSMB channel:

```
Guest VM process
    │
    ▼
NtCreateFile("\Device\STORVSP\VSMB\some\path")
    │
    ▼
storvsp!VspVsmbFileCreate
    │   No caller auth check
    ▼
storvsp!VspVsmbCommonRelativeCreate
    │
    ▼
ZwOpenDirectoryObject(\Device\xxx)   ← host device opened without auth
```

| Element | Value |
|---|---|
| Device path | `\Device\STORVSP\VSMB` |
| Vulnerable functions | `storvsp!VspVsmbFileCreate`, `storvsp!VspVsmbCommonRelativeCreate` |
| Bypass function | `storvsp!VspVsmbGetStatInfo` (Flags bit) |
| Privileges | VM guest user (no host credentials required) |
| SKU | Server with Hyper-V role (VSMB enabled) |

---

## Detection engineering

- **Hyper-V VMBus telemetry**: Monitor for VSMB file-create requests from guest
  VMs targeting non-guest paths (e.g., `\Device` namespace traversal).
- **Host ETW**: `Microsoft-Windows-Hyper-V-Storage` provider may log abnormal
  VSMB create operations.
- **Behavioral tell**: Guest VM opening host `\Device` objects through VSMB
  is anomalous — no legitimate guest workload should do this.

## References

- [MSRC — CVE-2025-59516](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59516)
- [78 Research Lab — VSMB missing auth](https://blog.78researchlab.com/2ffdb461-3e5b-8066-8856-cd04baee34dc)