EDK II - Improper Update of Reference Count in TcpCloneTcb

Executive Summary

TcpCloneTcb calls NET_GET_REF(Tcb->IpInfo) at line 551 to increment the reference count of the shared IP_IO_IP_INFO. When SockClone fails at line 558 (returning NULL because SockCreate hit an allocation failure or, deterministically, because the listening socket's ConnCnt has reached its BackLog at SockImpl.c:657-665), the function frees the Clone TCB (FreePool(Clone) at line 560) and returns NULL without decrementing the IpInfo reference. The caller TcpInput receives NULL and goes to DISCARD — the IpInfo reference is permanently leaked. A leaked reference keeps the IP I/O instance alive past its intended lifetime, preventing proper cleanup. This is reachable from a remote TCP peer sending a SYN to a listening socket, which only exists when a UEFI application or driver calls TCP Accept; the standard network boot paths (PXE, HTTP boot, iSCSI) act as TCP clients and do not listen.

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/TcpDxe/TcpMisc.c:551
• Function: TcpCloneTcb
• Category: Improper Update of Reference Count (CWE-911)

Technical Details

Controllability: EXTERNAL_UNTRUSTED — Confidence: HIGH

Data Flow

The vulnerable variable is Tcb->IpInfo (IP_IO_IP_INFO pointer to shared IP I/O info). The trace begins at TcpDriver.c:371, where TcpRxCallback is registered as the IP I/O packet-received callback. At TcpIo.c:36, the attacker-controlled network packet is passed into TcpInput. At TcpInput.c:852, TcpInput detects a SYN flag on a listening socket, triggering child TCB creation. At TcpInput.c:858, TcpInput calls TcpCloneTcb(Parent) to create a child TCB. At TcpMisc.c:551, TcpCloneTcb increments IpInfo->RefCnt via NET_GET_REF(Tcb->IpInfo). At lines 558-561, when SockClone fails (returns NULL under memory pressure, or when the listener's backlog is full), Clone is freed via FreePool(Clone) and NULL is returned — but the IpInfo reference is not decremented. At TcpInput.c:866, the caller goes to DISCARD with no IpInfo cleanup, permanently leaking the reference.

Affected Callers

• TcpInput (TcpInput.c:858)

Sanitization / Security Controls

None identified. No authentication exists at the TCP layer for incoming SYN segments.

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 (requires a UEFI application or driver that listens on a TCP port; standard network boot paths do not)

Reproduction

1. Identify a TCP port on which a UEFI application or driver is listening (TCP Accept).
2. Send TCP SYN packets until the listener's backlog is full (Parent->ConnCnt == Parent->BackLog).
3. Each further SYN makes SockCreate return NULL, and TcpCloneTcb leaks one IpInfo reference.

Impact

The IP_IO_IP_INFO reference count is left too high, so that IpInfo is never freed when the socket is torn down: a one-off small memory leak. RefCnt is an INTN (IpIoLib.h:298) incremented by a plain NET_GET_REF, so wrapping it is not practical, and additional leaked references do not cause further harm.

Remediation and Mitigation

As of commit 70741a15d9a714323a5598eac47727e60507e22f this issue is unfixed upstream and no CVE has been assigned. Release the reference on every exit path, including early error returns, so the reference count stays balanced. 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