EDK II - Out-of-bounds Read in PxeBcParseVendorOptions

Executive Summary

PxeBcParseVendorOptions iterates over PXE sub-options within DHCP option 43 using an outer loop guarded by Offset < VendorOptionLen. Each sub-option's per-tag CopyMem reads a fixed-size field from PxeOption->Data (e.g., 4 bytes for EFI_IPv4_ADDRESS, 2 bytes for ports, up to 10 bytes for multicast allocation fields) without first verifying that PxeOption->Length is at least as large as the required field size. A rogue DHCP server can craft option 43 with a trailing sub-option whose declared Length is smaller than the tag-implied fixed read, causing a read past that sub-option's data. The over-read is at most 10 bytes and stays inside the fixed-size cached packet buffer (PXEBC_CACHED_DHCP4_PACKET_MAX_SIZE, PxeBcDhcp4.h:257/262) or the adjacent fields of the same PXEBC_DHCP4_PACKET_CACHE structure, and the bytes read are stored in VendorOpt.

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/UefiPxeBcDxe/PxeBcDhcp4.c:109
• Function: PxeBcParseVendorOptions
• Category: CWE-125 (Out-of-bounds read)

Technical Details

Controllability: EXTERNAL_UNTRUSTED — confidence: HIGH (pattern and LLM agreement)

Data Flow

The attack surface begins at PxeBcDhcp4CallBack (PxeBcDhcp4.c:1174), the EFI_DHCP4_PROTOCOL callback invoked during PXE boot DHCP exchange, receiving a DHCP4 OFFER/ACK packet from a DHCP server. On Dhcp4RcvdOffer the flow proceeds through PxeBcCacheDhcp4Offer (line 1294) → PxeBcParseDhcp4Packet (line 826) → PxeBcParseVendorOptions (line 535, only when the offer carries the PXEClient class identifier). At line 96, VendorOptionLen = Dhcp4Option->Length sets the loop bound from the attacker-controlled UINT8 length field of option 43. At line 102, the while ((Offset < VendorOptionLen) && (PxeOption->OpCode != DHCP4_TAG_EOP)) loop guard only ensures the sub-option header starts within the parent data. At line 109, the vulnerable sink CopyMem(&VendorOption->MtftpIp, PxeOption->Data, sizeof(EFI_IPv4_ADDRESS)) reads 4 bytes without checking PxeOption->Length >= 4. The worst case is at lines 162–164, where reads from Data+0, Data+4, and Data+6 (10 bytes total) occur without verifying PxeOption->Length >= 10. Loop advancement at line 197 uses the declared Length, not the actual bytes read — the over-read already occurred.

Affected Callers

• PxeBcParseDhcp4Packet
• PxeBcDhcp4CallBack
• PxeBcCacheDhcp4Offer
• EfiPxeBcDiscover
• EfiPxeBcDhcp

Sanitization / Security Controls

• Outer loop bound Offset < VendorOptionLen at PxeBcDhcp4.c:102 — partial: ensures sub-option header starts within parent option 43 data, but does not verify the fixed-size Data read fits within the sub-option's declared Length. Over-read is bounded within the cached packet buffer or the adjacent fields of the same cache structure.

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 DHCP server; wait for target DHCP DISCOVER; craft DHCP OFFER with option 60 set to PXEClient and option 43 containing a PXE sub-option (e.g., OpCode=1 MTFTP_IP) whose declared Length is smaller than the fixed-size read (e.g., Length=1 but tag implies a 4-byte read); send the crafted OFFER.

Impact

Small bounded OOB read of at most 10 bytes inside the cached DHCP packet buffer or the adjacent fields of the same cache structure. The bytes end up in the parsed PXE vendor fields (MTFTP IP/ports, multicast allocation, boot item), so the attacker mostly gets back bytes it supplied itself. No heap memory is read and no crash occurs.

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.

References

• EDK II source (TianoCore)
• Affected file at the referenced commit