# CVE-2026-58530 — Windows ReFS `refs.sys` Checkpoint `globalTableCount` Not Bounded to Destination → Heap Buffer Overflow (Mount-Time RCE)

---

## Summary

| | |
|---|---|
| **Product** | Windows — `refs.sys` (Resilient File System / ReFS driver) |
| **CVE ID** | CVE-2026-58530 |
| **Impact** | Remote Code Execution (local; kernel arbitrary code execution) |
| **MSRC severity** | Important |
| **CVSS** | 7.8 / 6.8 — `CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C` |
| **CWE** | CWE-122: Heap-based Buffer Overflow (kernel out-of-bounds write) |
| **Delivery** | Local — user mounts a specially crafted ReFS image |
| **KB / Fixed build (diffed lineage, Server 2022)** | KB5099540 — `refs.sys` 10.0.20348.5386 |
| **Other affected SKUs** | 24H2 `26100.8875`, 25H2 `26200.8875`, 26H1 `28000.2525`, Server 2025 `26100.33158`, Server 2019/2016, Win10 (per MSRC) |
| **Patch Date** | July 14, 2026 (2026-Jul) |
| **Pre-patch binary** | `refs.sys` 10.0.20348.4893 — SHA256 `a69d3df36a5917b354c7ef791745e2c729866365db6ff5f3020e790e1fe1ea7a` |
| **Post-patch binary** | `refs.sys` 10.0.20348.5386 — SHA256 `d7d7569d7b0fe668ff31221f5b1bcd7801b84b0fec60f4392d2e1368e6fcf0a8` |
| **Feature flag** | `Feature_1337977145` / `Feature_3102454072` — **the fix is CFR-gated** |
| **Exploitability** | Exploitation Unlikely; not publicly disclosed; not exploited (per MSRC) |

> Lineage note: this diff is the **Server 2022 (build 20348)** pair `.4893 → .5386`
> (KB5099540). The same fix ships across the affected ReFS SKUs. Analysis corroborated by
> an independent writeup (CVE-2026-58530); functions and offsets match the ghidriff.

---

## Product Description

`refs.sys` is the **Resilient File System (ReFS)** driver. During volume mount it reads the
on-disk **checkpoint** and validates it (`CmsVolume::ReadLatestCheckpoint` →
`CmsVolume::ValidateCheckpointRecord`); later it re-serializes a checkpoint to disk
(`CmsVolume::FormatCheckpointRecord`). A checkpoint record carries a **global table entry
count** (`globalTableCount`) as the DWORD at `record + 0x90`, followed by an offset table.

---

## Vulnerability Summary

This is a **producer/consumer bug separated in time**. A crafted checkpoint can carry an
excessive `globalTableCount` at `record + 0x90`. Pre-patch, `ValidateCheckpointRecord`
accepted the count as long as it was **internally consistent with the input record** — the
key check `count <= size >> 2 && count > 4` bounds the count only against the *input
checkpoint's own size*, so a larger crafted record simply raises the permitted count (a
0x4000-byte record allows count up to 0x1000). It says nothing about the **destination**
buffer. During mount, `ReadLatestCheckpoint` promotes the value into persistent kernel
state as `volume + 478 = count - 13` (extended-root count), losing all memory of its
untrusted origin. Later, `FormatCheckpointRecord` restores `count = volume[478] + 13` and
writes that many offset-table entries and serialized roots into the **fixed checkpoint
record buffer** — **with no comparison of the final cursor against that buffer's size** — a
kernel heap out-of-bounds write (CWE-122). Reaching the path only requires a user to
**mount a crafted ReFS image** (`AV:L`, `UI:R`), yielding kernel code execution.

---

## Prerequisites and Constraints

- Local; no privileges (`PR:N`) but user interaction (`UI:R`): the victim mounts a
  specially crafted ReFS image / VHD.
- The image's checkpoint carries a `globalTableCount` (e.g. `0x160`) that passes the
  record-local checks but exceeds what the destination checkpoint buffer can hold.
- Result: `FormatCheckpointRecord` serializes too many entries/roots past the buffer.

---

## Vulnerability Details

### Root Cause

`globalTableCount` was validated only relative to the input record's size (and offset-table
consistency), never against the size of the destination checkpoint buffer it later drives.
The accepted count is stored into the volume object (`count - 13`) and restored later
(`count = [478] + 13`) unchanged, so the formatter writes an attacker-chosen number of
entries with no destination bound.

### The patch (confirmed — diff, .4893 → .5386)

The formatter (`FormatCheckpointRecord`) is logically unchanged (only relocated); the
CVE-relevant delta is an **absolute count cap added to `ValidateCheckpointRecord`**, gated
behind the CFR flag, so the oversized count is rejected at read time before it is promoted
to persistent state:

```c
// CmsVolume::ValidateCheckpointRecord — PRE (record-local check only)
uVar1 = *(uint*)((char*)record + 0x90);        // globalTableCount
if (uVar1 <= size >> 2 && uVar1 > 4) {         // bound is the INPUT size — not a real limit
    // ... offset-table entries must lie inside the record (record-local checks) ...
}

// POST (10.0.20348.5386) — an ABSOLUTE cap is enforced (Feature_1337977145 / Feature_3102454072)
uVar1 = *(uint*)((char*)record + 0x90);
if (feature_enabled && uVar1 > MAX_GLOBAL_TABLE_COUNT)   // *** reject oversized count ***
    return 0;                                            // checkpoint rejected before promotion
if (uVar1 <= size >> 2 && uVar1 > 4) { ... }
```

With `globalTableCount` capped to what the destination checkpoint buffer can actually hold,
the value promoted into `volume[478]` and later restored by `FormatCheckpointRecord` can no
longer drive an out-of-bounds serialization, closing the overflow at the validator (the
sink in the formatter is left unchanged).

### Patch Completeness Assessment

**CFR-gated behind `Feature_1337977145` / `Feature_3102454072`.** The cap runs only when the
flag is enabled; the original record-local-only validation still ships when disabled. Verify
the flag is enabled to confirm the fix is live. Because the sink in `FormatCheckpointRecord`
is unchanged, the defense depends entirely on the validator rejecting the oversized count.

---

## Detection Guidance

**Behavioural.** Pool-corruption / bugcheck crashes in `refs!CmsVolume::FormatCheckpointRecord`
(or `ValidateCheckpointRecord`) when mounting ReFS volumes/VHDs on unpatched/flag-disabled
builds; a ReFS bugcheck/invariant failure (`0x149` trace) during checkpoint persistence.
Restrict mounting of untrusted ReFS images / VHDs; treat attacker-supplied disk images as
dangerous.

**Config.** The fix is CFR-gated — confirm `Feature_1337977145` is enabled.

---

## References

- MSRC advisory — CVE-2026-58530 (Windows Resilient File System (ReFS) Remote Code Execution), released 2026-07-14, KB5099540 (Server 2022) and per-SKU KBs.
- Full binary diff: `/data/patch_diffs/refs_sys-cve-2026-58530-ghidriff.md`