EDK II - Improper Update of Reference Count in TcpQueueData

Executive Summary

TcpQueueData unconditionally calls NET_GET_REF(Nbuf) at line 561, incrementing NET_BUF.RefCnt from 1 to 2. However, on four early-return paths the buffer does not stay in the receive queue and the reference is never decremented: (1) line 598 — duplicate segment detected, before insertion; (2) line 602 — TcpTrimSegment returns 0, before insertion; (3) line 628 — subsequent segment fully overlaps Nbuf, which is removed from RcvQue again at line 627; (4) line 633 — TcpTrimSegment returns 0 for subsequent overlap, and Nbuf is removed at line 632. The sole caller TcpInput calls NetbufFree(Nbuf) exactly once on all exit paths, decrementing RefCnt from 2 to 1 — never reaching 0, so the NET_BUF and its NET_VECTOR are permanently leaked (NetbufFree releases only at RefCnt == 0, NetBuffer.c:203-211). The data path is reached only for segments that pass the sequence acceptance test (TcpInput.c:1044) on an established connection, so the sender must be the TCP peer (for example the HTTP boot server) or an on-path party that knows the sequence window.

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/TcpInput.c:561
• Function: TcpQueueData
• Category: Improper Update of Reference Count (CWE-911)

Technical Details

Controllability: EXTERNAL_UNTRUSTED — Confidence: HIGH

Data Flow

The vulnerable variable is Nbuf (NET_BUF pointer to the received TCP segment). The trace begins at TcpDriver.c:371, where TcpRxCallback is registered as the IP I/O packet-received notification callback for all incoming TCP packets. At TcpIo.c:36, TcpRxCallback passes the raw attacker-controlled NET_BUF directly into TcpInput with attacker-controlled source and destination addresses. At TcpInput.c:1487, TcpInput calls TcpQueueData(Tcb, Nbuf) for out-of-order data queueing. At TcpInput.c:561, TcpQueueData unconditionally increments Nbuf->RefCnt from 1 to 2 via NET_GET_REF(Nbuf). On the early-return path at line 598 (duplicate segment), the function returns 1 without calling NET_PUT_REF and without inserting Nbuf into RcvQue. Back in TcpInput at line 1529 (or 1538 / 1553 on the drop paths), the caller calls NetbufFree(Nbuf) once, decrementing RefCnt from 2 to 1 — the buffer is never freed since RefCnt never reaches 0, permanently leaking the NET_BUF and its NET_VECTOR.

Affected Callers

• TcpInput (sole caller, line 1487)

Sanitization / Security Controls

• Sequence acceptance test (TcpInput.c:1044): data segments must fall inside the receive window of an established connection. This limits the attacker to the connection peer or an on-path party; it does not prevent the leak.

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

Reproduction

1. Act as the TCP peer of an established connection from the firmware (for example the HTTP boot server), or as an on-path party that knows the sequence window.
2. Send an out-of-order data segment so it is queued in RcvQue, then send in-window data segments that are fully covered by it (or that overlap it) to trigger the early-return paths at lines 598, 602, 628 or 633.
3. Repeat to accumulate leaked buffers until UEFI pool memory is exhausted.

Impact

Each crafted out-of-order segment leaks one NET_BUF and its NET_VECTOR. Repeated segments can exhaust UEFI pool memory and cause a denial of service during network boot. There is no memory corruption, and the parties able to send such segments (the connection peer or an on-path party) can already stall or break the transfer.

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