Tianocore/edk2.git/NetworkPkg/TcpDxe, branch dependabot/github_actions/actions/setup-python-7

NetworkPkg: Remove redundant Status initializations

2026-06-04T15:32:31+00:00

Remove redundant Status = EFI_SUCCESS and Status = EFI_DEVICE_ERROR initializations that are immediately overwritten before being read, across multiple modules: Dhcp6Dxe, DnsDxe, HttpBootDxe, HttpDxe, Ip4Dxe, Ip6Dxe, MnpDxe, Mtftp4Dxe, Mtftp6Dxe, SnpDxe, TcpDxe, TlsAuthConfigDxe, UefiPxeBcDxe and WifiConnectionManagerDxe. Cc: Saloni Kasbekar Cc: Zachary Clark-williams Signed-off-by: abuthahirm

NetworkPkg/TcpDxe: Skip RST when no IpIo sender exists for Dst

2026-05-25T08:41:54+00:00

Unknown or closed segments still go down the RST path into TcpSendIpPacket. When no IpIo sender exists for the destination, each packet logs “No appropriate IpSender.” next to the usual discard traces and floods the console. The change calls IpIoFindSender before SEND_RESET and discards when it fails, which stops that storm and leaves normal RST behavior unchanged when a sender is present. Cc: Saloni Kasbekar Cc: Zachary Clark-williams Cc: Mike Beaton Signed-off-by: Matthew Graham

NetworkPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

NetworkPkg TcpDxe: Fixed system stuck on PXE boot flow in iPXE environment

2024-05-30T21:06:38+00:00

This bug fix is based on the following commit "NetworkPkg TcpDxe: SECURITY PATCH" REF: 1904a64 Issue Description: An "Invalid handle" error was detected during runtime when attempting to destroy a child instance of the hashing protocol. The problematic code segment was: NetworkPkg\TcpDxe\TcpDriver.c Status = Hash2ServiceBinding->DestroyChild(Hash2ServiceBinding, &mHash2ServiceHandle); Root Cause Analysis: The root cause of the error was the passing of an incorrect parameter type, a pointer to an EFI_HANDLE instead of an EFI_HANDLE itself, to the DestroyChild function. This mismatch resulted in the function receiving an invalid handle. Implemented Solution: To resolve this issue, the function call was corrected to pass mHash2ServiceHandle directly: NetworkPkg\TcpDxe\TcpDriver.c Status = Hash2ServiceBinding->DestroyChild(Hash2ServiceBinding, mHash2ServiceHandle); This modification ensures the correct handle type is used, effectively rectifying the "Invalid handle" error. Verification: Testing has been conducted, confirming the efficacy of the fix. Additionally, the BIOS can boot into the OS in an iPXE environment. Cc: Doug Flick [MSFT] Signed-off-by: Sam Tsai [Wiwynn] Reviewed-by: Saloni Kasbekar

NetworkPkg TcpDxe: SECURITY PATCH CVE-2023-45236

2024-05-24T15:48:52+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4541 REF: https://www.rfc-editor.org/rfc/rfc1948.txt REF: https://www.rfc-editor.org/rfc/rfc6528.txt REF: https://www.rfc-editor.org/rfc/rfc9293.txt Bug Overview: PixieFail Bug #8 CVE-2023-45236 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Updates TCP ISN generation to use a cryptographic hash of the connection's identifying parameters and a secret key. This prevents an attacker from guessing the ISN used for some other connection. This is follows the guidance in RFC 1948, RFC 6528, and RFC 9293. RFC: 9293 Section 3.4.1. Initial Sequence Number Selection A TCP implementation MUST use the above type of "clock" for clock- driven selection of initial sequence numbers (MUST-8), and SHOULD generate its initial sequence numbers with the expression: ISN = M + F(localip, localport, remoteip, remoteport, secretkey) where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection's identifying parameters ("localip, localport, remoteip, remoteport") and a secret key ("secretkey") (SHLD-1). F() MUST NOT be computable from the outside (MUST-9), or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the TCP connection parameters and some secret data. For discussion of the selection of a specific hash algorithm and management of the secret key data, please see Section 3 of [42]. For each connection there is a send sequence number and a receive sequence number. The initial send sequence number (ISS) is chosen by the data sending TCP peer, and the initial receive sequence number (IRS) is learned during the connection-establishing procedure. For a connection to be established or initialized, the two TCP peers must synchronize on each other's initial sequence numbers. This is done in an exchange of connection-establishing segments carrying a control bit called "SYN" (for synchronize) and the initial sequence numbers. As a shorthand, segments carrying the SYN bit are also called "SYNs". Hence, the solution requires a suitable mechanism for picking an initial sequence number and a slightly involved handshake to exchange the ISNs. Cc: Saloni Kasbekar Cc: Zachary Clark-williams Signed-off-by: Doug Flick [MSFT] Reviewed-by: Saloni Kasbekar

NetworkPkg: SECURITY PATCH CVE-2023-45237

2024-05-24T15:48:52+00:00

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug #9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar Cc: Zachary Clark-williams Signed-off-by: Doug Flick [MSFT] Reviewed-by: Saloni Kasbekar

NetworkPkg: RFC1323 definition changed to RFC7323

2024-01-16T01:17:34+00:00

According to UEFI spec 2.10, the definition of RFC1323 has changed to RFC7323 on EFI_TCP6_OPTION. So align this change on NetworkPkg. REF: UEFI spec 2.10 section 28.2.5 Signed-off-by: Suqiang Ren Cc: Saloni Kasbekar Cc: Zachary Clark-williams Reviewed-by: Saloni Kasbekar

NetworkPkg: Fix conditionally uninitialized variables

2023-04-03T15:29:08+00:00

Fixes CodeQL alerts for CWE-457: https://cwe.mitre.org/data/definitions/457.html Cc: Erich McMillan Cc: Jiaxin Wu Cc: Maciej Rabeda Cc: Michael D Kinney Cc: Michael Kubacki Cc: Siyuan Fu Co-authored-by: Erich McMillan Signed-off-by: Michael Kubacki Reviewed-by: Michael D Kinney Reviewed-by: Oliver Smith-Denny

NetworkPkg/TcpDxe: Fix debug macro arguments

2022-09-09T01:42:39+00:00

Removes Status argument that is not needed from DEBUG macros. Cc: Maciej Rabeda Cc: Jiaxin Wu Cc: Siyuan Fu Signed-off-by: Michael Kubacki Reviewed-by: Maciej Rabeda

NetworkPkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the NetworkPkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Maciej Rabeda