# CVE-2024-30078 — Windows Wi-Fi Driver `nwifi.sys` Out-of-Bounds Access via a Missing 802.1Q VLAN Length Check in `Dot11Translate80211ToEthernetNdisPacket`

---

## Summary

| | |
|---|---|
| **Product** | Microsoft Windows — `nwifi.sys` (Native Wi-Fi / NDIS filter driver) |
| **CVE ID** | CVE-2024-30078 |
| **Impact** | Remote Code Execution — **unauthenticated, network-adjacent (over-the-air)** |
| **MSRC severity** | Important |
| **CWE** | CWE-20: Improper Input Validation → out-of-bounds read/write |
| **Patch Date** | June 11, 2024 |
| **Pre-patch binary** | `nwifi.sys` 10.0.22621.3527 (vulnerable) — SHA256 `91c6281add525124de76e3cdf13c3ede455979eb9408c46ef51ff9af14bab4d9` |
| **Post-patch binary** | `nwifi.sys` 10.0.22621.3733 (Jun 11 2024 fix) — SHA256 `b856587cf18c8417dec6a4ed56024e759015d6b093aea4dd603bb460f9663a37` |
| **Fix gating** | Length check appears **unconditional** (a new `Feature_1281542463` exists in the diff but gates other selective-translation work) |

---

## Product Description

`nwifi.sys` is the **Native Wi-Fi** NDIS filter driver, sitting between the
protocol and miniport drivers to translate inbound IEEE 802.11 frames into
Ethernet frames. Its `ReceiveNetBufferListsHandler` (`Pt6Receive`) converts each
received `NET_BUFFER_LIST` into an `MSDU`, then
`ExtSTAReceivePacket` → `ExtSTAReceiveDataPacket` →
`Dot11Translate80211ToEthernetNdisPacket` reformats the frame **in place**,
building the Ethernet header in front of the payload. Because the frame comes off
the air, this path processes attacker-controlled input from any device on the
same Wi-Fi network — **no authentication**, network-adjacent (the RCE Microsoft
rated Important).

---

## Vulnerability Summary

`Dot11Translate80211ToEthernetNdisPacket` reads the 8-byte LLC/SNAP header after
checking the buffer holds 8 bytes. When the LLC type is `0x8100` (802.1Q VLAN),
an **additional 4-byte IEEE 802.1Q header** follows — but the pre-patch code
**did not check that those 4 bytes are present** before reading them and before
computing where to write the Ethernet header:

```c
// Dot11Translate80211ToEthernetNdisPacket — VLAN offset selection (per Crowdfense)
// Case 4: LLC->type == 0x8100 && vlanid >= 0x600
//   v17 = LLC_offset - 0xE + 4 + 8   ->  Ethernet header written past the MDL buffer
```

With `LLC->type == 0x8100` and no data after the 8-byte LLC, the driver reads the
VLAN header out of bounds and, in "case 4", the Ethernet-header write lands past
the end of the `_MDL`-described buffer — an out-of-bounds read leading to an
out-of-bounds write in kernel memory.

---

## Prerequisites and Constraints

- **Network-adjacent, unauthenticated.** The attacker must be on the same Wi-Fi
  network (e.g. a rogue AP the target associates to, or an open network); no
  credentials. Delivered as an 802.11 data frame.
- The malicious frame sets LLC type `0x8100` and must satisfy the `tpid` /
  `vlanid` checks to reach the vulnerable offset (case 4).
- Crowdfense assessed practical exploitation as constrained: the overwritten
  region (a `0x7800` adapter buffer) and lack of a paired info-leak limit impact
  to corrupting an adjacent packet — the fix is nonetheless a real OOB access.

---

## Vulnerability Details

### Call Chain

```
Over-the-air 802.11 data frame (unauthenticated, same Wi-Fi net):
  nwifi!Pt6Receive  (ReceiveNetBufferListsHandler)
    → ExtSTARecvInitializeMSDUFromNBL   (NBL -> MSDU)
      → ExtSTAReceivePacket → ExtSTAReceiveDataPacket
        → Dot11Translate80211ToEthernetNdisPacket   [*** OOB read/write ***]
```

### Root Cause

The 802.11→Ethernet translation validates the 8-byte LLC header length but not
the extra 4 bytes required when the LLC type is `0x8100` (VLAN). It then reads the
VLAN header and derives the Ethernet-header write offset from it, so a frame that
claims VLAN without carrying the 4 VLAN bytes reads/writes outside the frame
buffer (CWE-20 → OOB).

### The patch (confirmed — diff, .3527 → .3733)

The patched `Dot11Translate80211ToEthernetNdisPacket` adds the missing length
check for the VLAN case — before reading the 802.1Q header it verifies the buffer
holds the extra 4 bytes (LLC 8 + VLAN 4 = 0xC beyond the header offset), and bails
if not:

```c
// Dot11Translate80211ToEthernetNdisPacket (10.0.22621.3733) — PATCHED, from our diff
if (uVar13 == 0x81) {                                   // LLC type == 0x8100 (byte-swapped)
    if ((vlan_case) && (available < *(uint *)(param_2 + 0xc) + 0xc))
        goto LAB_0;                                      // *** not enough for the 4-byte 802.1Q -> bail ***
    vlan = *(ushort *)(buf + llc_off + 8);               // now safe to read the VLAN header
    ...
}
```

The added `available < data_length + 0xc` test ensures the VLAN header (and the
Ethernet header that would be built from it) stays within the buffer, closing the
out-of-bounds access.

### Patch Completeness Assessment

The VLAN length check in the `0x8100` branch is applied on the receive path and
reads as **unconditional** (the June 2024 fix; the `Feature_1281542463` flag added
in the same build gates unrelated selective-translation work, not this bounds
check). Patch state is determined by file version.

---

## Detection Guidance

**Network / RF.** Inbound 802.11 data frames whose SNAP/LLC type is `0x8100`
(VLAN) but that carry no valid 802.1Q payload — anomalous for legitimate traffic.
Rogue-AP / evil-twin monitoring on managed Wi-Fi.

**Crash signature.** Bugchecks in `nwifi!Dot11Translate80211ToEthernetNdisPacket`
on Wi-Fi receive, correlated with association to an untrusted/open network.

**Config.** Prefer authenticated/enterprise Wi-Fi; avoid auto-connect to open
SSIDs. File-version check suffices (fix not feature-gated).

---

## References

- Crowdfense — *Windows Wi-Fi Driver RCE Vulnerability – CVE-2024-30078*
  (aleksandr.k, voidsec).
- MSRC advisory — CVE-2024-30078
- Full binary diff: `/data/patch_diffs/nwifi_sys-cve-2024-30078-ghidriff.md`