Public Security Advisories
Coordinated vulnerability disclosures from Argus. Findings, impact, and remediation, published in good faith.
The PEI-phase 64-bit counterpart of XhcInitializeEndpointContext64.
In FvIsBeingProcessed, a KNOWN_HANDLE is allocated with AllocatePool(sizeof(KNOWN_HANDLE)) but only guarded by ASSERT(KnownHandle != NULL) — a no-op in RELEASE builds.
In the XenStore string-list parsing helper Split, Dst = AllocatePool(*NumPtr * sizeof(CHAR8 *) + Len) has NO NULL CHECK before CopyMem at line 233 writes through it via &Dst[*NumPtr].
In XenStoreJoin, Buf = AllocatePool(BufSize) is guarded only by ASSERT(Buf != NULL) — a no-op in RELEASE builds.
In XenStoreVSPrint, Buf = AllocateZeroPool(BufSize) has NO NULL CHECK before it is passed to AsciiVSPrint(Buf, BufSize, FormatString, Marker) at line 1383 and to XenStoreWrite at line 1384.
In the XenBusDxe driver binding Start function (XenBusDxeDriverBindingStart, line 312), Dev = AllocateZeroPool(sizeof(*Dev)) has NO NULL CHECK before Dev->Signature = XENBUS_DEVICE_SIGNATURE at line 350 dereferences it.
In XenStoreProcessMessage, a XENSTORE_MESSAGE is allocated with AllocateZeroPool(sizeof(XENSTORE_MESSAGE)) without checking for NULL.
In XenStoreRegisterWatch, a XENSTORE_WATCH is allocated with AllocateZeroPool(sizeof(XENSTORE_WATCH)) without checking for NULL.
In CreateTransferRing, UsbHcAllocateMem (which returns NULL on failure) is called, but only an ASSERT(Buf != NULL) guards the result.
Multiple unchecked allocations lead to NULL pointer dereference in RELEASE builds during USB device slot initialization.
The SMM driver dispatcher allocates an EFI_SMM_DRIVER_ENTRY with AllocateZeroPool but only guards it with ASSERT(DriverEntry != NULL), which compiles to a no-op in RELEASE.
In UpdateVariableInfo, a VARIABLE_INFO_ENTRY is allocated with AllocateZeroPool guarded only by ASSERT — a no-op in RELEASE.
In CreateEventRing, two UsbHcAllocateMem calls are guarded only by ASSERT (DEBUG-only, no-op in RELEASE) before ZeroMem dereferences the result.
TcpQueueData unconditionally calls NET_GET_REF(Nbuf) at line 561, incrementing NET_BUF.RefCnt from 1 to 2.
TcpCloneTcb calls NET_GET_REF(Tcb->IpInfo) at line 551 to increment the reference count of the shared IP_IO_IP_INFO.
In the TAIL branch of Ip4TrimPacket (lines 162–168), the trim length is computed as Len = End - Info->End (INTN).
A remote pre-auth network attacker can send a DHCPv4 reply packet with HwAddrLen > 16 (range 0–255) during PXE/DHCP boot.
PxeBcSelectBootMenu iterates over variable-length PXEBC_BOOT_MENU_ENTRY structures from the DHCP4 vendor option 43 BOOT_MENU sub-option (tag 9) using a loop guarded only by MenuSize > 0 (line 314), which only proves at least 1 byte remains — insufficient for the 3-byte struct header (UINT16 Type + UINT8 DescLen).
On the Silicon Labs Secure Element port, wolfSSL sized an ECC import from the encoded point and selected the curve separately by identifier. A 133-byte point on a P-256 session wrote past the 96-byte key_raw field during certificate processing, before the handshake was authenticated.
U-Boot's IP fragment reassembly writes into the reassembly buffer using attacker-controlled fragment offset and length without adequate bounds checking, so a crafted fragmented packet sent during netboot writes out of bounds and corrupts adjacent memory.
U-Boot's RLE8 bitmap decoder does not bound its writes to the framebuffer, so a crafted RLE8-compressed BMP decoded during boot writes past the end of the framebuffer and corrupts adjacent memory inside the bootloader.
A size computation for the SquashFS directory table overflows on an attacker-controlled superblock field, producing an undersized allocation and subsequent out-of-bounds writes when U-Boot parses a crafted SquashFS image during boot.
U-Boot's NFS client stores the server-supplied READ length in a signed integer and bounds it with a pointer-difference check that a negative length passes, then copies it as an unsigned length, so a malicious NFS server can drive an approximately 2 GB out-of-bounds write.
U-Boot's NFS client takes the symlink length from a READLINK reply into a signed integer with no lower-bound check, so a negative length bypasses the capacity guard and is then used as an unsigned copy size, giving a malicious NFS server an out-of-bounds write off the path buffer.
On a storage failure U-Boot's lwIP wget receive callback aborts and frees the TCP connection but returns the wrong status code, so the lwIP TCP input path keeps using the freed connection object, a use-after-free reachable from a malicious HTTP server.
// No embargoed advisories on this page.