EDK II - Out-of-bounds Read in HttpBootParseDhcp6Packet
HttpBootParseDhcp6Packet calls AsciiStrLen((CHAR8 *)Options[HTTP_BOOT_DHCP6_IDX_BOOT_FILE_URL]->Data) at line 273 on the raw DHCPv6 OFFER/REPLY boot-file-URL option bytes.
- Advisory
- BYTERAY-2026-0223
- CWE
- CWE-125
- Vendor
- TianoCore
- Product
- EDK II
- Reported
- 2026-06-25
- Disclosure
- 2026-10-29
- Affected
- EDK II at commit 70741a15d9a714323a5598eac47727e60507e22f (master, 2026-06-21); affected code in NetworkPkg/HttpBootDxe/HttpBootDhcp6.c.
- Credit
- Argus-Systems
Executive Summary
HttpBootParseDhcp6Packet calls AsciiStrLen((CHAR8 *)Options[HTTP_BOOT_DHCP6_IDX_BOOT_FILE_URL]->Data) at line 273 on the raw DHCPv6 OFFER/REPLY boot-file-URL option bytes. The option carries a declared OpLen field (network order), but AsciiStrLen scans byte-by-byte until \0 with no length bound — its only guard is an ASSERT that is a no-op in RELEASE firmware builds. A rogue DHCPv6 server can craft a BOOT_FILE_URL option whose Data region contains no NUL byte, causing AsciiStrLen to read past the option's declared OpLen into the following options and the rest of the packet cache buffer. The packet was first copied by HttpBootCacheDhcp6Packet (lines 329-342) into the fixed-size cache Private->OfferBuffer[n].Dhcp6 (HTTP_CACHED_DHCP6_PACKET_MAX_SIZE, HttpBootDhcp6.h:71,76), so the scan runs over that buffer (stale bytes from an earlier offer in the same slot, or zeros) and, only for a full 1472-byte packet, into the next fields of the same cache structure, which contain zero bytes. The read does not leave driver-owned memory. The unbounded length is then passed as the UrlLen argument to HttpParseUrl (lines 271–276).
This advisory is one of a set reported to VulnCheck on 2026-06-25 for coordinated disclosure to the EDK II maintainers. After several follow-ups over the following months no response was received. 126 days after the initial report, ByteRay is publishing the findings in good faith so that affected integrators can assess and remediate them. All findings were identified against EDK II commit 70741a15d9a714323a5598eac47727e60507e22f (master, 2026-06-21).
Affected Products and Versions
- Vendor: TianoCore
- Product: EDK II (
NetworkPkg) - Affected commit:
70741a15d9a714323a5598eac47727e60507e22f(master, 2026-06-21). The code is present on that commit and later revisions that have not changed it. - Location:
NetworkPkg/HttpBootDxe/HttpBootDhcp6.c:273 - Function:
HttpBootParseDhcp6Packet - Category:
CWE-125 / CWE-170 (Out-of-bounds read via unbounded AsciiStrLen on missing NUL termination)
Technical Details
Controllability: EXTERNAL_UNTRUSTED — confidence: HIGH (pattern and LLM agreement)
Data Flow
The attack surface begins at HttpBootDhcp6CallBack (HttpBootDhcp6.c:417), the EFI_DHCP6_PROTOCOL callback invoked during HTTP boot DHCPv6 exchange. It receives DHCPv6 OFFER/REPLY packets from a DHCPv6 server — fully attacker-controlled by a rogue DHCPv6 server. The flow proceeds through HttpBootCacheDhcp6Offer (line 355) → HttpBootParseDhcp6Packet (line 379). At line 273, the vulnerable sink executes: (UINT32)AsciiStrLen((CHAR8 *)Options[HTTP_BOOT_DHCP6_IDX_BOOT_FILE_URL]->Data) scans byte-by-byte until \0 with no length bound — the option's declared OpLen field (network order UINT16) is NOT used as a bound. The scan stays inside the cached packet buffer Private->OfferBuffer[n].Dhcp6 that HttpBootCacheDhcp6Packet filled at line 338. The over-long length is then passed as UrlLen to HttpParseUrl at lines 271–276, so bytes from later options or stale cache contents become part of the parsed URL.
Affected Callers
HttpBootCacheDhcp6OfferHttpBootDhcp6CallBack
Sanitization / Security Controls
- Option declared
OpLenfield on the DHCP6 option (EFI_DHCP6_PACKET_OPTION->OpLen, network order UINT16) — ineffective: exists butAsciiStrLendoes not useNTOHS(OpLen)as a bound. ASSERTinAsciiStrLen(String.c:647,655) — ineffective: no-op in RELEASE firmware builds.- No sanitization points were identified.
Reachability and Preconditions
Attacker position and trust level for this issue are stated in the Controllability line and Data Flow above, and the concrete trigger is in Reproduction below.
Exploitability: Low
Realism: Medium
Reproduction
Set up rogue DHCPv6 server on the local link; wait for DHCPv6 SOLICIT; craft a DHCPv6 ADVERTISE/REPLY containing the "HTTPClient" vendor class option and a BOOT_FILE_URL option (option 59) whose Data contains no NUL byte; send the crafted packet. Firmware processes it: AsciiStrLen at line 273 scans past the option's declared OpLen into the following options of the cached packet; the over-long length is passed to HttpParseUrl.
Impact
The URL string is read past the DHCPv6 option's declared OpLen into the following options and stale bytes of the fixed offer cache buffer. The read stays within driver-owned memory, so there is no crash and nothing is returned to the attacker; the extra bytes can end up in the URL parsed by HttpParseUrl, a minor integrity issue in the boot URL.
Remediation and Mitigation
As of commit 70741a15d9a714323a5598eac47727e60507e22f this issue is unfixed upstream and no CVE has been assigned. Before reading each field, validate that its full width fits within the remaining bytes derived from the packet or record size, and stop parsing or reject the input when it does not. The specific control that is absent or ineffective is identified in the Sanitization / Security Controls list under Technical Details.
Timeline
- 2026-06-25 - Reported to VulnCheck for coordinated disclosure to the TianoCore / EDK II security team.
- 2026-07 to 2026-10 - Several follow-ups sent; no response received.
- 2026-10-29 - Public disclosure in good faith, 126 days after the initial report.
Credits
Discovered and reported by Argus-Systems.