EDK II - Buffer Overflow via Wrong Bounds Check in DHCP4 Packet Cache in PxeBcCacheDhcp4Packet

Executive Summary

The bounds check at line 425 compares Dst->Size (total buffer allocation = 1480 bytes) against Src->Length (network-controlled, data-only length). However, CopyMem(&Dst->Dhcp4, &Src->Dhcp4, Src->Length) at line 429 writes starting at &Dst->Dhcp4 (offset 8), where only 1472 bytes are available. When Src->Length is in the range [1473, 1480], the copy overflows the 1480-byte PXEBC_DHCP4_PACKET union by 1–8 bytes into the adjacent OfferType field of PXEBC_DHCP4_PACKET_CACHE (PxeBcDhcp4.h:265-268), inside PXEBC_PRIVATE_DATA. The Dhcp4RcvdAck callback case at line 1316 lacks the Packet->Length > PXEBC_DHCP4_PACKET_MAX_SIZE guard present in Dhcp4RcvdOffer (1281), Dhcp4SendDiscover (1239), and Dhcp4SendRequest (1254), leaving the full ACK path unguarded. Offers, and replies collected by PxeBcDhcp4Discover (guard at line 1529), are limited to 1472 bytes, so only the ACK path is affected. The same wrong length then reaches the mode-data copy at line 643: when PxeBcHandleDhcp4Offer calls PxeBcCopyDhcp4Ack(Private, Ack, TRUE) at line 1141, Ack->Length (up to 1480) is written into the 1472-byte EFI_PXE_BASE_CODE_PACKET Mode->DhcpAck, overflowing up to 8 bytes into the adjacent Mode->ProxyOffer (PxeBaseCode.h:289-290). A UDP payload of 1473–1480 bytes exceeds a 1500-byte Ethernet MTU, so the ACK must be IP-fragmented; Ip4Dxe reassembles fragments (Ip4Input.c:787).

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:425 (copy at line 429; second copy at line 643)
• Function: PxeBcCacheDhcp4Packet
• Category: Buffer Access with Incorrect Length Value

Technical Details

Controllability: EXTERNAL_UNTRUSTED — confidence: high

Data Flow

Dhcp4Io.c:979 sets Packet->Length = UdpPacket->TotalSize from network-received UDP packet data → PxeBcDhcp4.c:1683 registers PxeBcDhcp4CallBack as the DHCP4 callback → PxeBcDhcp4.c:1316–1323 the Dhcp4RcvdAck case has NO length guard (unlike Dhcp4RcvdOffer at line 1281 which checks > 1472) and calls PxeBcCopyDhcp4Ack(Private, Packet, FALSE) → PxeBcDhcp4.c:633 calls PxeBcCacheDhcp4Packet with the network-controlled packet → PxeBcDhcp4.c:425–429 the bounds check Dst->Size (1480) < Src->Length passes when Src->Length is in [1473, 1480], but CopyMem(&Dst->Dhcp4, &Src->Dhcp4, Src->Length) writes at offset 8 where only 1472 bytes are available, causing a 1–8 byte overflow into the adjacent OfferType field. → PxeBcDhcp4Dora (line 1741) → PxeBcHandleDhcp4Offer → PxeBcCopyDhcp4Ack(Private, Ack, TRUE) (line 1141) → line 643 CopyMem(&Mode->DhcpAck.Dhcpv4, &Ack->Dhcp4, Ack->Length) overflows the 1472-byte Mode->DhcpAck by up to 8 bytes into Mode->ProxyOffer.

Affected Callers

• PxeBcCopyDhcp4Ack
• PxeBcHandleDhcp4Offer
• PxeBcDhcp4CallBack
• PxeBcDhcp4Dora

Sanitization / Security Controls

• Dhcp4Io.c:963: minimum packet size check (UdpPacket->TotalSize < sizeof(EFI_DHCP4_HEADER)) — no maximum enforcement.
• Dhcp4Io.c:988–990: validates DHCP reply opcode and transaction ID — attacker who sniffs the client's DHCPDISCOVER can forge matching Xid.
• PxeBcDhcp4.c:1281: length guard exists for Dhcp4RcvdOffer but is ABSENT for Dhcp4RcvdAck — ineffective for the ACK path.
• PxeBcDhcp4.c:463 and :605: PxeBcParseDhcp4Packet zeroes OptList and rewrites OfferType before they are used, which limits the effect of the overflow at line 429.

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: Medium
Realism: Medium

Reproduction

1. Attacker on the same local network segment as the PXE-booting client; can sniff the client's DHCPDISCOVER to obtain the transaction ID (Xid); target uses UefiPxeBcDxe (built into OVMF/UEFI firmware).
2. Set up rogue DHCP server; observe client's DHCPDISCOVER to capture Xid and client hardware address.
3. Send crafted DHCP4 ACK with UDP payload Length in [1473, 1480], split into IP fragments so it fits the link MTU.
4. ACK passes DhcpInput validation (opcode, matching Xid, matching ClientHwAddr); Dhcp4RcvdAck callback fires with no length guard; CopyMem writes 1473–1480 bytes into a 1472-byte buffer.
5. When DORA completes, PxeBcHandleDhcp4Offer calls PxeBcCopyDhcp4Ack(Private, Ack, TRUE) and line 643 copies the same length into the 1472-byte Mode->DhcpAck, overwriting the start of Mode->ProxyOffer.

Impact

Remote, unauthenticated out-of-bounds write of up to 8 attacker-controlled bytes during IPv4 PXE boot, staying inside the PXE driver's own structures. At line 429 the bytes land on PXEBC_DHCP4_PACKET_CACHE.OfferType and alignment padding on x64 (OfferType and OptList[0] on IA32), which PxeBcParseDhcp4Packet zeroes or rewrites before use (lines 463, 605). At line 643 the bytes overwrite the start of Mode->ProxyOffer in EFI_PXE_BASE_CODE_MODE. No heap metadata or function pointers are reached, so code execution is not demonstrated; the effect is corruption of adjacent PXE packet data.

Remediation and Mitigation

As of commit 70741a15d9a714323a5598eac47727e60507e22f this issue is unfixed upstream and no CVE has been assigned. Derive the bounds check from the destination buffer size and validate the copy length before the copy. 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