EDK II - Memory Leak in HttpBootGetBootFile

Executive Summary

When an HTTP server responds with 401 Unauthorized and a WWW-Authenticate header, HttpBootGetBootFile allocates Private->AuthScheme via AllocateZeroPool (line 1486). If that allocation returns NULL, the function executes a direct return EFI_OUT_OF_RESOURCES (line 1488) instead of branching to the goto cleanup chain (ERROR_5 at line 1783, falling through ERROR_4/ERROR_3/ERROR_2/ERROR_1). This bypasses cleanup for five previously allocated objects: ResponseData, RequestData, HttpIoHeader, Url, and Cache. The leak is OOM-gated (only fires when the pool is already exhausted), so it amplifies an existing exhaustion condition rather than initiating one, but the direct return is a clear defect.

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/HttpBootClient.c:1488
• Function: HttpBootGetBootFile
• Category: Memory Leak (CWE-401)

Technical Details

Controllability: EXTERNAL_UNTRUSTED — confidence: high

Data Flow

The HTTP boot state machine (HttpBootGetBootFileCaller at HttpBootImpl.c:379/406/443) calls HttpBootGetBootFile, which allocates five objects in sequence: Url (line 1168), Cache (line 1201), HttpIoHeader (line 1236), RequestData (line 1378), and ResponseData (line 1417). It then receives an HTTP response from the network via HttpIoRecvResponse (line 1424). If the status code is 401/407 (line 1434), the function looks up the WWW-Authenticate header (line 1480) and attempts to allocate AuthScheme using the length of the attacker-controlled HttpHeader->FieldValue plus one as the size (line 1486). If AllocateZeroPool returns NULL (OOM), the function executes return EFI_OUT_OF_RESOURCES directly (line 1488), bypassing the ERROR_5→ERROR_4→ERROR_3→ERROR_2→ERROR_1 cleanup chain (lines 1783–1805) and leaking all five prior allocations.

Affected Callers

• HttpBootLoadFile (HTTP boot entry path)

Sanitization / Security Controls

• AuthData/AuthScheme already-set check (lines 1437–1450): only gates the second 401 response; first 401 proceeds to the vulnerable allocation.
• NULL check on AuthScheme (line 1487): present, but the handling (direct return) is the defect — it should branch to goto ERROR_5.
• No authentication gates this path — it is the authentication challenge phase itself.

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: Low

Reproduction

1. Firmware performs HTTP/PXE boot; attacker controls the HTTP server (rogue DHCP, spoofing); UEFI pool already under significant memory pressure (OOM gate).
2. Position attacker-controlled HTTP server.
3. Wait for firmware HTTP request.
4. Respond with 401 and WWW-Authenticate header.
5. If pool is exhausted, AllocateZeroPool for AuthScheme fails and the direct return leaks five structures; firmware retries per state machine, accumulating leaks.

Impact

Amplifies existing pool exhaustion; firmware has no virtual memory, so leaked pools persist until reboot. The HTTP server cannot force the allocation to fail on a healthy system, so the effect is limited to a small leak during a boot that is already short of memory, which can at most cause that boot attempt to fail.

Remediation and Mitigation

As of commit 70741a15d9a714323a5598eac47727e60507e22f this issue is unfixed upstream and no CVE has been assigned. Validate the attacker-controlled value described above before it is used; the specific missing control is identified under Technical Details. 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