If you don't work on computer firmware, here is what this is about.

Before a computer's operating system starts, a smaller program built into the machine, its firmware, gets the hardware ready and starts the system. UEFI is a standard for that firmware. EDK II is free, open-source code for building UEFI firmware, maintained by a community called TianoCore, and OVMF is the version of it made for virtual machines: computers simulated in software, such as the rented cloud servers this essay is mostly about.

One feature, called PXE, lets a machine start up over the network instead of from its own disk. In October 2026 TianoCore fixed a flaw in it: while a machine is starting this way, an attacker who can send it a crafted network error message (ICMP is the standard kind) may be able to run their own code on it 3.

The fix is in the source code, but that isn't the same as being in the firmware a given machine runs, and on a rented cloud server you can't easily look. This essay explains why the usual patch-status pages can't answer that question, and describes how one would check.

CVE-2026-97631 (GHSA-99cj-7hg9-mp4m) identifies a remote code execution vulnerability (a flaw that can let an attacker run their own code on the machine from across a network) within the TianoCore EDK II NetworkPkg/UefiPxeBcDxe driver (the part of the firmware that handles network booting), specifically affecting the PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle functions. The upstream fix was merged into the master branch on October 15, 2026, but as of October 31, 2026 no upstream stable release contains it; the latest is edk2-stable202608, dated August 21, 2026. Distro security trackers (the patch-status pages Linux distributions such as Debian and Ubuntu publish) assess source packages, release by release, which does not tell you the state of the firmware a particular machine loads. A cloud VM runs firmware the host selects, not firmware from its own disk image, which leaves the tenant (the customer renting the machine) little view of its patch state. Where the provenance of the loaded firmware is not enough, verification means parsing the Firmware Volume (the container inside a firmware file that holds its modules), finding the UefiPxeBcDxe module by its GUID (a fixed identifying number), and checking that both ICMP error handlers clamp each copy to the space left in the buffer. Remediation is firmware that contains the fix; until then, avoid unnecessary PXE boots, isolate provisioning networks, and filter ICMP errors before they reach the booting machine. This essay describes the check. It has not yet run it on any shipped firmware.

• Upstream fix (PR #13302) merged October 15, 2026; no stable release contains it yet (edk2-stable202608 is last).
• Distro trackers (Debian, SUSE, Ubuntu) report source status, not firmware binary content.
• A cloud VM runs host-selected firmware, not firmware from its disk image; the host's loader configuration determines exposure.
• Verification: parse the Firmware Volume for the UefiPxeBcDxe GUID, then check that both ICMP error handlers clamp each copy to the space left. No shipped binary has been checked here yet.
• Until fixed firmware ships: avoid unneeded PXE boots, isolate provisioning networks, filter ICMP errors upstream of the machine.

• Cloud Security Engineers: Guest OS package updates do not patch the virtual firmware; relying on apt upgrade or dnf update provides false assurance of remediation.
• DevOps & Infrastructure: Automated provisioning pipelines using PXE boot may expose instances to remote code execution via ICMP during the network boot phase, prior to OS initialization.
• Compliance Auditors: A tracker's "Fixed" describes a distribution package, not the binary firmware actually executing on customer infrastructure.
• System Administrators: Disabling unused boot protocols in the hypervisor (the software on the provider's physical server that runs the virtual machines) configuration reduces the attack surface, as network boot is frequently left enabled for legacy compatibility.

Drafts here go through the Moot before I read them: a panel of frontier models I call by their lab bosses' first names (Dario, Sam, Sundar), plus Eddie, the house model that drafts. Two outside readers critiqued the first version, and checking their points showed that most of Sam's Moot corrections had never been ruled on, so they never reached the text. They are applied now. Every source was re-read on 31 October 2026. No firmware binary has been inspected yet: the method here is a plan, not a result.

There's a real gap between when CVE-2026-97631 was fixed and when you can get that fix in a stable, production release. The vulnerability lives in the EDK II NetworkPkg, the component that handles UEFI network boot services. Two functions are involved: PxeBcIcmpErrorDpcHandle for IPv4 and PxeBcIcmp6ErrorDpcHandle for IPv6, both of which process incoming ICMP error packets. A large or fragmented ICMP error message triggers an out-of-bounds write: the copy loop gets the room left in the buffer wrong, and the destination pointer advances by the cumulative copied length rather than by the length of each fragment 2.

TianoCore merged the fix via Pull Request #13302 on October 15, 2026 1. The commits are 14cdbb86a1a4f9bcce0d6cb78b04af58f226cf48, 560ed9b5b146ed622d7eb7c40254a9099bd65b84, and fa789071ff0b29f1e568bfe153ef7f3d76bd60e41. They do three different things. 14cdbb86 adds tests. 560ed9b5 is the overflow fix: in both handlers it clamps each copy to the space left in the 504-byte Mode.IcmpError buffer, stops when the buffer is full, and advances the pointer by what was actually copied 2. fa789071 clears the buffer with ZeroMem first, so a short message no longer leaves stale bytes from an earlier one 1. The advisory was published on October 22, 2026 3.

The stable release cadence does not reflect that merge yet. The next planned stable tag is edk2-stable202611, and no stable tag yet contains the fix; the latest is edk2-stable202608, released August 21, 2026 4. So the codebase is fixed while the tagged releases downstream distributors actually build from are not. Microsoft Project Mu's mu_basecore release v2026080000.0.5, published October 26, 2026, lists the backport 5. A component release does not tell you which finished firmware products have picked it up.

The advisory publication date and the upstream patch status come from the official CVE List record and the GitHub repository history 9, 1. The advisory's "any network distance" wording suggests the attack does not require local proximity; it relies on unicast ICMP during the PXE phase, which runs before the operating system's firewall rules are active. If a virtual machine is set to boot from the network, the hypervisor hands a virtual NIC to the guest firmware, and malicious ICMP packets injected into the virtual network can reach the PXE driver.

Distance is not the same as reachability, though. The attacker has to get an ICMP error message addressed to the client's IP to it while it is PXE-booting 3. The obvious case is a shared provisioning segment or a flat L2 network. It is harder wherever something upstream filters ICMP errors, and whether a given cloud network lets such a packet through depends on the provider's filtering, which this essay has not tested. Hetzner, for one, treated its own network as a path: on October 30, 2026 it began dropping fragmented ICMPv4 and ICMPv4 errors of 768 bytes or more 15.

The gap between upstream merge and stable release is not merely a timing annoyance; it reaches into the supply chain. Downstream distributors compile EDK II into binary firmware files, typically named OVMF_CODE.fd or a close variant, pre-built by the distribution maintainers. When a tracker says "vulnerable," it often refers to the source repository behind that package. If the source has not picked up the upstream fix commits, the binary is assumed vulnerable. But the binary is the only state the guest firmware cares about: in principle a source package marked "Fixed" could still ship a vulnerable binary, if the backport was incomplete. That is a risk to check for, not something this essay has observed for this CVE.

The Project Mu backport pins a specific component version with the fix, which is distinct from the mainline EDK II stable releases. Organizations relying on Project Mu binaries sit in a different posture than those pulling generic edk2-ovmf packages from Linux distributions. The next upstream stable tag is edk2-stable202611, but vendors need not wait for it: they can backport the fix and ship their own firmware, as Project Mu did 5.

The CVSS v4.0 score assigned to this vulnerability is 9.5 3, reflecting the potential for unauthenticated remote code execution when the target is in the PXE boot state. SUSE gives a CVSS 3.1 score of 8.8 with vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H6, and Red Hat publishes the same. The two scores use different CVSS versions and different attack vectors (TianoCore's is AV:N ), and neither vendor page says why it chose adjacent network.

For the defender, the critical question is whether the specific firmware binary on their instance contains the semantic fix. Since the fix lives in the logic of the copy loop, what matters is which source revision and downstream patches a build used, not when it was built: an old checkout can be compiled today, and a backport can predate the merge (560ed9b5 was written on September 28 2 ). If trustworthy provenance says which revision went in, that answers it. If not, compare against a validated fixed build, or inspect the binary itself.

Security trackers are the main tool administrators use to gauge exposure, and their reliability depends entirely on what they actually track. For UEFI firmware, the gap between source package status and binary artifact state is the whole ballgame. Debian marks the source package edk2 as vulnerable or unfixed across the bookworm, trixie, and forky/sid branches 7. SUSE marks the overall status as Pending 6. Ubuntu marks the status as Needs evaluation 8. Every one of those labels is a package-level assessment for a distribution release. None of them identifies the firmware a particular VM actually loads.

Calling a source package "vulnerable" means the source files in the repository still contain the flaw. Update the source to the fixed upstream commit and the label should flip to "Fixed." But that flip says nothing about whether the compiled binaries shipped in the repository packages carry the semantic change. Binary reproducibility is a known challenge in firmware compilation (compiler flags, optimization levels, and linking environments can all alter the output from identical source code), and distributions may delay the binary update even after the source is updated. This essay has not found a package labeled fixed that ships an unfixed binary; it is a gap to check, not a finding.

The BS Detector Deluxe methodology tests exactly that claim against the binary content. A "Fixed" label is a promise about source, not a receipt for your binary. If binary analysis shows that either ICMP error handler still copies without clamping to the space left, or still advances by the cumulative length, the claim is falsified. A missing ZeroMem call proves nothing on its own: the clearing is a separate commit, and a compiler can inline it. The tracker status is a signal, not proof.

Debian's status is specific to the source package. If Debian's edk2 still has the flawed copy loop, without 560ed9b5 or an equivalent backport, the package is vulnerable. 14cdbb86 only adds tests, so whether it is there settles nothing. Debian also ships binary packages, and the security of an installed instance depends on whether that binary was built from the patched source; the tracker does not expose the binary package's build timestamp relative to the fix commit.

SUSE's overall state is "Pending", but its product table already marks ovmf Affected 6. Read the product rows, not the headline label. Neither says anything about the binary on your host.

Ubuntu's "Needs evaluation" means the review is still open. Until it closes, treat the package as potentially affected. That is a risk-management choice, not a finding.

The deeper problem is that firmware is a distinct artifact from the operating system. In a standard Linux distribution, the edk2 source package compiles into OVMF firmware binaries, which get installed into system firmware directories or shipped as packages for VMs. Inside a guest, apt upgrade updates the guest's packages, not the firmware it booted with: the hypervisor selects that. On a virtualization host, upgrading the firmware package does install new firmware files, but you still have to confirm each VM loads the updated file.

So the tracker status only matters if the VM instance is configured to load a firmware binary that the distribution's package manager actually updates. On AWS, Azure, or GCP, the hypervisor supplies the firmware, and there is no dnf command running on the hypervisor host for you to call. The guest OS tracker status is therefore largely irrelevant for cloud instances: the hypervisor configuration determines the firmware, and if the hypervisor image has not been updated, the guest firmware stays vulnerable no matter how clean the guest OS patch level looks.

Comparing tracker status against expected binary state shows how opaque this gets. A package marked "Fixed" implies patched source; a binary built from that source should be fixed too. But a binary built earlier and never rebuilt is still vulnerable. A distribution that ships pre-built images without rebuilding them for each source change could end up with "Fixed" source and a vulnerable binary. That is a hypothetical to test for; no such case is documented for this CVE.

The BS Detector Deluxe check extracts the Firmware Volume (FV) from the OVMF_CODE.fd file. Tools such as uefi-firmware-parser or UEFITool handle the extraction. Then you locate the UefiPxeBcDxe module by its Module GUID B95E9FDA-26DE-48d2-8807-1F9107AC5E3A. If a complete parse shows the module is absent, this implementation of the bug is not in that image 10. Failing to find the GUID is not the same thing: a parse can fail, or a vendor can rename or rework the driver, and those cases are unknown, not safe. If the module is present, disassemble it and inspect both PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle.

The module is not in every build. Some distributions and vendor customizations disable PXE boot support to shrink the attack surface. In those cases the tracker can still report the source package as "vulnerable" (the source contains the driver) while the binary is safe (the driver was never compiled into the image). High-level tracker summaries lose that distinction entirely.

This gap between label and binary reality is a systemic issue in software supply chains. The tracker reflects the maintainers' intent; the binary reflects the state of the artifact. For firmware, the artifact is the firmware volume. Trusting the label over the volume is a comfortable mumpsimus (a mistaken habit kept after it has been shown wrong), and without parsing the firmware volume the tracker status is only an assumption.

Deciding whether the attack surface exists in a given binary comes down to one indicator: is the UefiPxeBcDxe module included? The module implements the Preboot Execution Environment (PXE) network boot protocol, and the vulnerability resides in its ICMP error handling logic. No module, no exploit.

The standard OVMF X64 build configuration (OvmfPkgX64.dsc ) enables NETWORK_PXE_BOOT_ENABLE by default 11, so stock OVMF_CODE.fd builds carry the PXE driver unless someone explicitly configured it out. Confirm its presence by the Module GUID B95E9FDA-26DE-48d2-8807-1F9107AC5E3A10. The GUID is unique to the module and stays constant across builds, unlike function prologue hashes, which shift with compiler optimizations.

The verification process involves the following steps:

1. Download the OVMF_CODE.fd file from the package mirrors or host storage.
2. Use uefi-firmware-parser or UEFITool to parse the Firmware Volume.
3. Search for the GUID B95E9FDA-26DE-48d2-8807-1F9107AC5E3A.
4. If found, extract the PE32+ image for the UefiPxeBcDxe module.
5. Locate both ICMP error handlers,PxeBcIcmpErrorDpcHandle andPxeBcIcmp6ErrorDpcHandle, allowing for inlining and other compiler transformations.
6. Check that each copy is clamped to the space left in the 504-byte buffer, that the loop stops when the buffer is full, and that the pointer advances by the length actually copied (FragmentLen ).
7. Check separately for the clearing before the loop (the ZeroMem from fa789071 ). Its absence alone does not mean the overflow is there.

This beats file hashing. A file hash changes if any part of the file changes, but it does not tell you whether the semantics changed. Any byte change, including unrelated build- environment differences, changes the hash, so a changed or unchanged hash tells you nothing about whether the fix is in. A secure hash that matches a trustworthy, independently validated fixed build does tell you that you have that build. A mismatch tells you nothing, and for a build nobody has validated, only inspecting the copy loop can confirm the fix.

Strings analysis (strings ) and symbol analysis (nm ) are insufficient. Do not assume a production firmware image carries function names. Use matching debug information if you have it; otherwise find the routines by analysing the code. Relying on strings can yield false negatives when the function name is obfuscated or removed; relying on hashes yields false positives when the build environment differs.

The build configuration decides what is included. UefiPxeBcDxe is compiled and placed in the firmware volume only when NETWORK_PXE_BOOT_ENABLE is true 12, and OvmfPkgX64.dsc sets it to true 11. The flag can be turned off without removing NetworkPkg, including with a command-line define, so read the effective build definitions, not just the DSC. Downstream distributors do sometimes change them, and those changes are not always reflected in the source tracker.

A census of the module GUID across distribution packages would show which ones ship the driver; nobody has run one yet, including us. A firmware image built without the PXE module does not have this bug at all. Some cloud workflows still need PXE, though: Hetzner's Rescue System boots that way 15.

The GUID B95E9FDA-26DE-48d2-8807-1F9107AC5E3A serves as the anchor for this verification. It is defined in the UefiPxeBcDxe.inf file of the EDK II repository 10. This is the INF (Information) file for the driver component, defining the module structure and GUIDs. Match the GUID found in the binary against the one defined in the INF file, and you have confirmed module identity without trusting symbol names.

The "PXE Flag" is effectively the presence of this module. Flag set (module present) means potentially vulnerable; flag unset (module absent) means not vulnerable to this. The catch is that the flag is not exposed inside the guest OS. It is a property of the firmware image the hypervisor loads.

Module absence does not make a system secure in all respects. It makes it secure against CVE-2026-97631, and nothing more; other modules can hold other vulnerabilities. For the scope of this research, the presence of the PXE driver is the primary risk factor.

The cloud environment adds a layer of indirection that obscures the firmware state from the tenant. The guest operating system runs inside a virtual machine made of virtual CPU, virtual RAM, virtual disk, and virtual network interface, and the virtual firmware (UEFI/ OVMF) is one more layer the hypervisor (e.g., KVM, Hyper-V, Xen) loads into virtual memory. It's turtles most of the way down.

Guest disk images do not contain the OVMF firmware. They hold the operating system kernel, user space, and data; the firmware is provided by the host hypervisor loader configuration. libvirt documents this: the <loader> configuration specifies the firmware path 13. Launch an EC2, Azure, or GCP instance and you do not upload your own firmware. You use the provider's default firmware or a provider-supplied image.

Because of that separation, updating the guest OS does not update the firmware. Run yumupdate on a guest instance and you patch the kernel and libraries, but the OVMF binary loaded at boot is unchanged. The firmware is not part of the file system. It is part of the virtual hardware configuration.

The measurement limit for cloud tenants is significant. They cannot easily inspect the firmware binary the host loads. Tools such as dmidecode report the firmware's own SMBIOS version strings, but those don't identify the PXE driver's source revision or patch state.

PCR0 (Platform Configuration Register 0) in TPM 2.0 attestation measures events, not binary patch state. On Google Compute Engine Shielded VMs, PCR0 measures only EV_S_CRTM_VERSION, EV_NONHOST_INFO and EV_SEPARATOR, which Google notes diverges from the TCG PC Client profile 14; PCR0 keeps one value for the life of the VM. Patched and vulnerable firmware can share a PCR0 value whenever the changed bytes are not measured, or the version string does not change.

So leaning on attestation to prove the fix is present is risky. Attestation is evidence about what was measured. Whether that state is patched depends on what the measurements cover and on trustworthy reference values, and Google's PCR0 alone doesn't tell you this driver's patch state.

The Cloud Shadow is that invisible firmware layer. Until the provider says which firmware build it loads, the honest status is unknown, and the prudent plan treats it as unpatched. Some providers publish firmware update logs; many do not. Amazon EC2 instances, for example, might use custom firmware builds that differ from the upstream EDK II stable releases.

Hetzner's October 29, 2026 update warns that its Cloud VMs running with UEFI are at risk when booting into the Rescue System 15. The Rescue System boots from the network, so the virtual NIC is active and the PXE driver is loaded. If the underlying firmware is vulnerable, that boot process is vulnerable, and it is a high-risk window because the Rescue System often has elevated privileges and network access to manage the primary instance.

Verifying the firmware in a cloud instance needs host access or provider cooperation. You cannot simply ssh into the hypervisor to run strings on the OVMF file, so you are left with documentation. AWS, Azure, and GCP do not always disclose the exact EDK II version used for a specific instance type, and they may update the firmware silently as part of the host maintenance cycle.

That opacity is what makes the Cloud Shadow a significant challenge. The best guess is that cloud providers update firmware periodically, but the exact timing and scope are unknown. The reasonable inference from the underlying host OS tracker status (e.g., Amazon Linux 2023) is not always applicable to the firmware.

Put plainly: the Guest OS runs in the VM. The Host Loader runs on the physical host. The Host Loader loads the Guest Firmware. The tenant controls the Guest OS; the provider controls the Host Loader and the Guest Firmware. A patch in the Guest OS never crosses the boundary into the Guest Firmware.

Since verifying patch state in cloud environments is hard, mitigation has to target the attack surface and network reachability. The first action is to disable PXE boot where it is not required. Standard cloud instances rarely use network boot after the initial provisioning; they launch from a pre-built image. Taking network boot out of the boot order closes the exposure window, since the bug is only reachable while a PXE boot is running 3.

In hypervisor configurations (e.g., libvirt), the <boot> element can be configured to remove the network boot option. This prevents the firmware Boot Device Selection phase from invoking the UefiPxeBcDxe driver to initiate a PXE boot session. The driver may still be loaded, but no PXE session starts, so its ICMP receive path never opens. Leaving the driver out of the build is a separate, build-time measure.

The second line of defense is network isolation. The bug needs an ICMP error message to arrive, so filtering ICMP errors upstream of the booting machine blocks the trigger. Standard security groups or firewall rules can drop ICMP traffic. Blanket ICMP blocking can disrupt Path MTU Discovery, and blanket ICMPv6 blocking can break essential IPv6 functions. Prefer provider-tested, temporary filtering or network isolation.

Where PXE boot is required (e.g., provisioning new instances), isolate the network segment and restrict PXE traffic to trusted provisioning servers. Untrusted network segments should not have access to the PXE boot channel.

The Hetzner Rescue System is a specific risk because it relies on PXE. Hetzner's advice is to avoid booting into it where possible, and, as an added precaution, to block incoming ICMP with the Hetzner Firewall during the boot 15. Where you activate it from doesn't matter; what matters is who can send packets to the VM while it boots.

Hypervisors and providers should filter ICMP at the virtual switch level, so that even a vulnerable firmware never sees the packets. That is a network-layer mitigation that holds regardless of the firmware state.

On-premises, the mitigation is more direct. The system BIOS/UEFI settings allow disabling network boot, and it should be disabled by default. Additionally, update the firmware to the latest stable release from the vendor, though, as noted, "stable release" does not guarantee the presence of the upstream fix if the vendor has not updated their EDK II source tree.

The defender flowchart: is PXE enabled? If yes, is ICMP allowed? Both true means high risk. PXE disabled means low risk. ICMP blocked means low risk.

The flowchart makes the dependency plain. Avoiding PXE boots is the most effective workaround because the vulnerable path never opens. Blocking ICMP errors is the next best because it removes the trigger. Neither replaces firmware with the fix.

Some data points stay unverified, held back by access limits or disclosure issues. The biggest gap is OEM firmware lag. 7 days passed between the upstream merge (October 15, 2026) and the advisory publication (October 22, 2026), but how long OEMs (e.g., Dell, HP, Lenovo) take to fold the fix into their BIOS/UEFI updates is unknown. OEM lag can be months. We cannot measure it in the current study, because we do not have access to the OEM firmware repositories.

Amazon Linux 2023's "Not Affected" status is confirmed by the Amazon Security Center (ALAS) page 16, but the reason is not. It could be the omission of the UefiPxeBcDxe driver (compile-time configuration), or a different fix being applied. The documentation does not specify. Without inspecting the exact build configuration and shipped artifacts, any reason we gave would be a guess. Amazon marks the AL2023 edk2 package Not Affected; the page does not say why, or say anything about the firmware EC2 actually runs.

The cross-distribution prevalence of shipped binary variants is unknown. We have no census of the OVMF_CODE.fd files in circulation. We have not sampled package mirrors or inspected any artifact, so how many vulnerable and fixed binaries are out there is unmeasured.

The persistence of the vulnerability in older firmware is assumed, but not measured. The flawed loops are already in the NetworkPkg import dated November 1, 2010 17. That is a fact about the source history, not proof that every firmware built since then is vulnerable: each artifact's code and patches still have to be checked.

The study duration is limited to the time elapsed since the advisory. No firmware binary was inspected for this essay. The check above is a proposal. The next step is to run it on OVMF builds whose state is known (one before the fix, one after, and one with only part of it) and confirm it tells them apart.

The novelty of the research is scoped to the submitted evidence. The review establishes neither a universal absence of prior research nor the proposed study's novelty beyond the specific scope of this verification.

1. Claim: A distro package marked "Fixed" ships firmware with the overflow fix in both ICMP error handlers.
   • Falsifier: Analysis of that package's OVMF_CODE.fd shows either handler still copies without clamping to the space left, or still advances by the cumulative length. One such package is enough. A missing ZeroMem call alone does not count.
2. Claim (hypothesis): On a given cloud, instances started after the provider's firmware update boot fixed firmware, and instances started before it do not.
   • Falsifier: In a sample fixed in advance (one instance type, started before and after the provider's announced update), firmware identified by a provider-attested method is the same in both groups. With no such method, the claim can't be tested from the tenant side, and that is the finding.
3. Claim (hypothesis): Amazon Linux 2023's edk2 is Not Affected because its build leaves out UefiPxeBcDxe.
   • Falsifier: The OVMF image in the AL2023 edk2 package contains the module GUID. The status would then rest on something else, such as a backport.
4. Claim: A SUSE ovmf package marked Affected, under the overall "Pending" state, ships firmware without the fix.
   • Falsifier: Binary analysis of one such package finds the fix in both handlers.

How:

• Download OVMF_CODE.fd from package mirrors.
• Extract Firmware Volume using uefi-firmware-parser or UEFITool.
• Locate UefiPxeBcDxe by GUID B95E9FDA-26DE-48d2-8807-1F9107AC5E3A.
• Disassemble PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle.
• Check both: each copy clamped to the space left, the loop stopping when the buffer is full, the pointer advancing by FragmentLen, not CopiedLen. Check the ZeroMem clearing separately.

How Not To:

• Do not hash the function prologue (compiler flags change this).
• Do not rely on strings or nm (don't count on symbols surviving).
• Do not call a missing GUID or a failed parse safe.
• Do not check guest disk image UUIDs for firmware version.
• Do not assume package manager status reflects guest VM firmware state.

Pseudocode for verification logic:

FUNCTION VerifyPatch(FirmwareImage):
    FV = ParseFirmwareVolume(FirmwareImage)
    IF FV IS INCOMPLETE:
        RETURN "UNKNOWN (parse incomplete)"
    MODULE = FindModuleByGUID(FV, "B95E9FDA-26DE-48d2-8807-1F9107AC5E3A")
    IF MODULE IS NULL:
        RETURN "ABSENT (upstream driver not found; look for a renamed one)"
    RESULTS = []
    FOR HANDLER IN ["PxeBcIcmpErrorDpcHandle", "PxeBcIcmp6ErrorDpcHandle"]:
        LOOP = FindCopyLoop(MODULE, HANDLER)
        IF LOOP IS NULL:
            RESULTS.append("UNKNOWN")
        ELSE IF LOOP clamps each copy to the space left, stops
                when the buffer is full, and advances by what it copied:
            RESULTS.append("FIXED")
        ELSE IF LOOP advances by the cumulative length:
            RESULTS.append("VULNERABLE")
        ELSE:
            RESULTS.append("UNKNOWN")
    IF "VULNERABLE" IN RESULTS: RETURN "VULNERABLE"
    IF EVERY RESULT == "FIXED": RETURN "FIXED"
    RETURN "UNKNOWN"

Record which file was inspected, and whether it is the file the VM actually loads.

• Claim: "My distro security tracker says 'Fixed', so I am patched."
  • Check: Distro trackers report source packages. Find out which firmware file the VM loads, then inspect it or match its hash to a validated fixed build.
• Claim: "My VM image is safe because I updated the OS."
  • Check: Guest OS updates do not replace hypervisor-supplied OVMF firmware.
• Claim: "I can detect the fix via the firmware file hash."
  • Check: A hash match to a validated fixed build is evidence; a mismatch is not. Otherwise, inspect the copy loop.
• Claim: "The vulnerability requires local network access."
  • Check: Upstream advisory allows delivery from any network distance via unicast ICMP during PXE. Red Hat/SUSE assign adjacent-network vectors for specific assessments.

Exposure here is binary: the driver is present and vulnerable, or it is absent or patched. The tracker describes a package, not the firmware a VM loads. The cloud architecture hides which one you have. The mitigation is manual, the cost is operational friction, and the risk is critical. The fix is upstream. Whether it reached the firmware booting your instance is, for now, unmeasured.

• OEM Lag: Only 7 days elapsed between upstream merge (Oct 15) and advisory (Oct 22). Months of lag cannot be confirmed yet.
• OEM Modifications: Vendor-customized firmware (Dell, HP) may break binary signatures; this study focuses on stock EDK II/OVMF distributions.
• Cloud Verification: We could not access host firmware binaries for AWS/Azure/GCP instances to confirm patch status; reliance is on provider documentation and attestation limitations.
• AL2023 Reason: "Not Affected" status on Amazon Linux 2023 requires vendor confirmation of compile-time configuration vs. other reasons.