microsoft/mu_basecore v2025110000.0.5

v2025110000.0.5

Repository: microsoft/mu_basecore

Tag: v2025110000.0.5

Published: 2026-03-27T23:05:59Z

Prerelease: no

Release notes:

What's Changed

[Cherry-Pick] Revert "MdeModulePkg/PciBusDxe: Degrade MEM64 to PMEM64… @apop5 (#1716)

Change Details

Description

This reverts commit f6489621b8ae1164c5e4930902988ba7c86847ba.

MdeModulePkg/PciBusDxe: Degrade MEM64 to PMEM64 when bridge lacks MEM64

A number of compatibility issues have been reported with this change to the PciBusDxe behavior. Revert this change at this time to give time for all the issues to be reviewed and options for supporting this new behavior to be evaluated and fully validated.

(cherry picked from commit defbd14d637313bdded40c717892497deec89be0)

• [ ] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

Booting windows on physical platform failed prior to revert.

Integration Instructions

No Integration necessary.

NetworkPkg/Dhcp6Dxe: Prevent potential infinite hang in EfiDhcp6Stop() @makubacki (#1722)

Change Details

Description

When a USB network adapter is removed while a DHCPv6 lease is active, the USB stack calls DisconnectController() at TPL_CALLBACK. The network stack teardown eventually invokes EfiDhcp6Stop(), which sends a Release message and enters a while loop polling Udp6->Poll() for the server's Reply:

while (Instance->UdpSts == EFI_ALREADY_STARTED) { Udp6->Poll (Udp6); }

This loop never terminates because:

1. The NIC hardware is physically gone 2. The timeout mechanism relies on Dhcp6OnTimerTick(), a timer event registered at TPL_CALLBACK. Since EfiDhcp6Stop() is already running at TPL_CALLBACK (called from DisconnectController()), the timer event does not fire. So, UdpSts is never updated, and the loop never exits.

Note: Dhcp6OnTimerTick() is not in the packet receive path.

Udp6->Poll() drives packet reception synchronously through the network stack (MNP -> IP6 -> UDP6 -> Dhcp6ReceivePacket()), and Dhcp6HandleReplyMsg() sets Instance->UdpSts = EFI_SUCCESS when a Release Reply arrives.

The timer event's role for Release messages is retransmission and to reach timeout. Which are blocked because of the TPL in this case.

This change removes the synchronous polling loop from EfiDhcp6Stop().

This matches how Dhcp4Dxe handles EfiDhcp4Stop() and EfiDhcp4Release(), which send the Release and immediately clean up without polling.

This is considered acceptable because:

• Dhcp6SendReleaseMsg() calls Dhcp6TransmitPacket(), which synchronously hands the packet to hardware by calling SNP->Transmit() before returning.

• The server acts on the Release immediately upon receipt per RFC 8415 Section 18.3.7. It does not wait for client acknowledgment.

• RFC 8415 Section 18.2.7 states:

"implementations SHOULD retransmit one or more times, but MAY choose to terminate the retransmission procedure early"

• The Release Reply carries no information we (the client) need.

• Dhcp6CleanupSession(), called immediately after sending Release, invokes Dhcp6CleanupRetry(DHCP6_PACKET_STATEFUL) which iterates TxList and frees the Release TxCb and its packet. The same memory cleanup occurs whether or not a Reply was received.

---

For reference: RFC 8415 Section 18.2.7

---

• [x] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

• PR is in draft while platform testing occurs

Integration Instructions

• N/A

Full Changelog: https://github.com/microsoft/mu_basecore/compare/v2025110000.0.4...v2025110000.0.5