A newly published issue in the EDK2 UEFI stack — tracked as CVE-2025-2295 — allows a malicious iSCSI target to craft a specially formed R2T (Ready To Transfer) PDU that can trigger an integer‑overflow condition and cause a BIOS/firmware implementation to read and return out‑of‑bounds memory, producing a remote memory‑exposure or denial‑of‑service outcome. This vulnerability was disclosed by the Tianocore/EDK2 project on March 14, 2025 and is described in the upstream advisory as a weakness in NetworkPkg/IScsiDxe that mishandles BufferOffset and DesiredDataTransferLength values in IScsiOnR2TRcvd.
EDK2 (the open‑source UEFI reference implementation maintained by the Tianocore community) implements a network boot and iSCSI DXE driver (NetworkPkg/IScsiDxe) used by many firmware builds and virtual‑machine OVMF images. The reported problem involves integer arithmetic on the 32‑bit BufferOffset and DesiredDataTransferLength fields taken from an R2T header; an attacker‑controlled value can overflow the offset+length check and allow the firmware to advance a pointer past the packet buffer, then generate Data‑Out PDUs that copy out-of-bounds memory back to the iSCSI target. The upstream advisory provides code excerpts and a technical walk‑through of how the overflow leads to out‑of‑bounds reads and remote memory exposure. Public vulnerability databases and commercial trackers capture the same headline: CVE‑2025‑2295 is scored as low (CVSS v3.1 base 3.5) in the public records, with attack vector network and primary impact focused on availability and information disclosure in some exploit scenarios. Multiple aggregator pages show the CVE details and link back to the upstream advisory. Microsoft’s Security Response Center (MSRC) entry for the CVE answers a common customer question with the line: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability,” and also notes Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE mappings if additional Microsoft products are discovered to ship the same upstream component. That MSRC phrasing is short, deliberate and procedural: it documents the inventory work Microsoft has completed so far for Azure Linux rather than asserting absolute exclusivity across every Microsoft artifact.
However, the same MSRC language should not be read as an absolute technical guarantee that no other Microsoft product contains the same EDK2 NetworkPkg/IScsiDxe code. The attestation is scoped: it reports the results of Microsoft’s inventory for Azure Linux at the time of publication. Microsoft has explicitly stated its VEX/CSAF rollout is phased (starting with Azure Linux in October 2025) and that it will expand attestations to other product families as the inventory work completes. In practice, this means:
The sentence on the MSRC page identifies Azure Linux as a product Microsoft has already inspected and confirmed to include the EDK2 iSCSI DXE component mapped to CVE‑2025‑2295. That is useful and actionable for Azure Linux users. But whether any other Microsoft artifact contains the same code is an artifact‑level question: it depends on the firmware or kernel image build pipeline, the versions of EDK2 used, and configuration choices (which modules are included, which DXE drivers are enabled).
Realistic Microsoft artifacts that could plausibly carry the same upstream code include:
The operational consequence is straightforward: treat Azure Linux as confirmed in‑scope; treat other Microsoft artifacts as unverified until Microsoft publishes additional attestations or until teams perform their own artifact checks.
Operational priorities are clear:
CVE‑2025‑2295 underscores a persistent reality of modern software supply chains: the same upstream open‑source component can appear in multiple products and images, and vendor attestations are a powerful tool — but they are most useful when paired with artifact‑level verification to close the long tail of unknowns.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
EDK2 (the open‑source UEFI reference implementation maintained by the Tianocore community) implements a network boot and iSCSI DXE driver (NetworkPkg/IScsiDxe) used by many firmware builds and virtual‑machine OVMF images. The reported problem involves integer arithmetic on the 32‑bit BufferOffset and DesiredDataTransferLength fields taken from an R2T header; an attacker‑controlled value can overflow the offset+length check and allow the firmware to advance a pointer past the packet buffer, then generate Data‑Out PDUs that copy out-of-bounds memory back to the iSCSI target. The upstream advisory provides code excerpts and a technical walk‑through of how the overflow leads to out‑of‑bounds reads and remote memory exposure. Public vulnerability databases and commercial trackers capture the same headline: CVE‑2025‑2295 is scored as low (CVSS v3.1 base 3.5) in the public records, with attack vector network and primary impact focused on availability and information disclosure in some exploit scenarios. Multiple aggregator pages show the CVE details and link back to the upstream advisory. Microsoft’s Security Response Center (MSRC) entry for the CVE answers a common customer question with the line: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability,” and also notes Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE mappings if additional Microsoft products are discovered to ship the same upstream component. That MSRC phrasing is short, deliberate and procedural: it documents the inventory work Microsoft has completed so far for Azure Linux rather than asserting absolute exclusivity across every Microsoft artifact.Technical anatomy: what CVE‑2025‑2295 actually does
How the iSCSI R2T PDU path is abused
- The firmware receives an R2T PDU from an iSCSI target and extracts a 32‑bit BufferOffset and DesiredDataTransferLength.
- The code converts network order fields to host order and assigns them to the transfer context.
- A bounds check attempts to ensure Offset + DesiredLength does not exceed Packet->OutTransferLength.
- Because Offset and DesiredLength are unsigned 32‑bit values, a large attacker‑supplied Offset can make Offset + DesiredLength wrap around and pass the check.
- The code then computes Data = Packet->OutDataBuffer + Offset and proceeds to generate Data‑Out PDUs that read from Data and transmit them back to the target — which may now point past the packet buffer and into adjacent firmware memory.
- The net result is an out‑of‑bounds read that the firmware will package and transmit, leaking memory contents to the remote iSCSI target under attacker control.
Scope and prerequisites for exploitation
- Exploitation requires that the vulnerable EDK2 iSCSI DXE driver (NetworkPkg/IScsiDxe) is present and used in the firmware or virtual‑machine OVMF image in question.
- The attacker must be able to act as or interpose an iSCSI target that the firmware or system connects to — this can be a local network adversary, an untrusted remote target the machine attempts to use during PXE/iSCSI boot, or a crafted target in virtualization scenarios where guest firmware interacts with virtual storage endpoints.
- The vulnerability is not a straightforward remote code execution primitive; the primary impacts are information disclosure (remote memory exfiltration) and denial of service if corrupted reads cause unexpected behavior. The public advisory and trackers classify it with a lower severity but caution that memory exposures in firmware or hypervisor contexts can have significant operational consequences.
What Microsoft said — and how to read the Azure Linux attestation
Microsoft’s short answer on the MSRC CVE page — that Azure Linux “includes this open‑source library and is therefore potentially affected” — is an authoritative product‑level attestation for Azure Linux images that Microsoft has inventory‑checked and published as machine‑readable CSAF/VEX metadata. That attestation gives Azure Linux operators a concrete, automatable signal: their images are confirmed carriers of the implicated upstream component and should be triaged and remediated accordingly.However, the same MSRC language should not be read as an absolute technical guarantee that no other Microsoft product contains the same EDK2 NetworkPkg/IScsiDxe code. The attestation is scoped: it reports the results of Microsoft’s inventory for Azure Linux at the time of publication. Microsoft has explicitly stated its VEX/CSAF rollout is phased (starting with Azure Linux in October 2025) and that it will expand attestations to other product families as the inventory work completes. In practice, this means:
- Azure Linux customers should treat Microsoft’s VEX/CSAF output for Azure Linux as canonical and urgent.
- Operators running other Microsoft‑distributed artifacts (WSL2 kernels, linux‑azure kernel packages, curated Marketplace images, AKS node images, or appliance images) cannot assume those artifacts are free from the same upstream component simply because they are not yet listed in MSRC VEX metadata. Absence of an attestation is an unknown status, not proof of safety.
Is Azure Linux the only Microsoft product that includes this open‑source library?
Short answer: No — not necessarily, and you should not assume exclusivity.The sentence on the MSRC page identifies Azure Linux as a product Microsoft has already inspected and confirmed to include the EDK2 iSCSI DXE component mapped to CVE‑2025‑2295. That is useful and actionable for Azure Linux users. But whether any other Microsoft artifact contains the same code is an artifact‑level question: it depends on the firmware or kernel image build pipeline, the versions of EDK2 used, and configuration choices (which modules are included, which DXE drivers are enabled).
Realistic Microsoft artifacts that could plausibly carry the same upstream code include:
- WSL2 kernel images or kernel sources used by Microsoft for Windows Subsystem for Linux, if a VM/firmware image containing EDK2 is used in a nested virtualization or appliance context.
- linux‑azure kernel packages and marketplace VM images that embed or reference specific OVMF/EDK2 builds.
- curated Azure Marketplace appliances and partner images that ship OVMF binaries or rely on vendor firmware bundles derived from EDK2.
- Any Microsoft‑published OVMF/EDK2 binary blobs used in cloud images or VM templates.
The operational consequence is straightforward: treat Azure Linux as confirmed in‑scope; treat other Microsoft artifacts as unverified until Microsoft publishes additional attestations or until teams perform their own artifact checks.
Cross‑verification of the technical facts (what independent sources say)
Multiple independent sources corroborate the technical claims in the Tianocore advisory:- The Tianocore/EDK2 security advisory (GHSA‑8522‑69fh‑w74x) lays out the code path in IScsiOnR2TRcvd, shows the integer‑overflow check bypass, and describes how out‑of‑bounds memory may be read and sent back in Data‑Out PDUs. This is the primary upstream record.
- OSV (the Open Source Vulnerabilities database) and other vulnerability aggregators (CVEDetails, cvefeed, Wiz) list CVE‑2025‑2295 and summarize the same attack vector (malicious R2T PDUs, integer overflow in IScsiDxe) and the CVSS scoring as referenced by Tianocore. These independent aggregators verify the existence and classification of the CVE.
- Multiple security trackers and bulletin pages that compile vendor advisories echo the same exploit model and note mitigation and patch guidance tied to EDK2 updates. Where vendor or distribution patches exist, distributors record fixed package versions; where upstream patches have not been released as distribution packages, the advisory remains the canonical fix source (upgrading to an updated EDK2 snapshot or vendor firmware).
Strengths and gaps in Microsoft’s attestation approach
Notable strengths
- Machine‑readable CSAF/VEX attestation is a real win. Publishing VEX/CSAF metadata for Azure Linux enables automated triage in large environments and reduces triage time when customers use vendor attestations as an input to patch orchestration. Microsoft’s commitment to machine‑readable outputs improves transparency for Azure Linux customers.
- Product‑scoped inventory reduces noise. By attesting the product families Microsoft has checked, MSRC gives defenders a clear starting point for remediation: if your asset runs a named product in MSRC VEX, you can act immediately with high confidence.
Potential risks and gaps
- Phased rollouts create a verification burden. Because Microsoft started with Azure Linux and is expanding VEX coverage over time, many Microsoft artifacts will be in an unknown state until inventory completes. Operators must therefore perform artifact‑level verification and not assume unlisted Microsoft artifacts are safe.
- Firmware/OVMF distribution complexity. EDK2 is included in firmware builds, OVMF images, vendor firmware packages, and Marketplace VM images. That breadth makes universal vendor attestations challenging; defenders must instead rely on SBOMs, binary scans, or vendor‑specific advisories to reach full coverage.
- Timing and release gaps. Upstream advisories sometimes precede vendor patches. The GitHub advisory in this case reported “Patched versions: None” at the moment of publication, which suggests vendors or downstream packagers may need to produce their patched firmware or images; this lag increases short‑term operational risk. Where a formal vendor patch release is absent, organizations must apply compensating controls until a patch is available.
Practical recommendations — a prioritized checklist for administrators and firmware engineers
- Patch Azure Linux immediately if you run it. Microsoft’s VEX attestation makes this a high‑priority item for Azure Linux customers. Monitor Microsoft update guidance and apply the vendor‑supplied kernel or package updates as published.
- Inventory all artifacts that may include EDK2/IScsiDxe:
- For firmware: collect firmware versions, vendor build identifiers and OVMF binaries; query SBOMs if available.
- For VMs and images: identify OVMF/EDK2 versions in Marketplace images, curated appliances and any custom images.
- For virtualization hosts: verify whether any VM templates include OVMF blobs compiled from EDK2 versions older than the advisory’s affected range.
- Consume machine‑readable VEX/CSAF feeds and automate mapping:
- Ingest MSRC VEX data where provided.
- Map binary artifacts to upstream component commit IDs using SBOM or binary hashing.
- Apply short‑term compensating controls until patches are deployed:
- Do not connect hosts/firmware to untrusted iSCSI targets.
- Restrict iSCSI network access to trusted management networks and enforce allow‑lists.
- In virtualized environments, isolate VM templates and Marketplace images until they are validated or updated.
- If vendor patches are not available:
- Request a firmware update or patched OVMF image from your hardware or image vendor.
- Consider replacing OVMF images with vendor‑patched builds or a known‑good snapshot.
- Scan and validate using tooling:
- Use SBOM and binary scanners to detect the presence of NetworkPkg/IScsiDxe and the commit ranges referenced by the advisory.
- For hypervisor images, extract OVMF binaries and compare against known vulnerable checksums or compiled object lists.
- Monitor logs and telemetry for anomalous iSCSI activity and unexpected Data‑Out PDUs during firmware network sessions.
How to confirm presence/absence (concrete checks)
- Inspect firmware/OVMF metadata and release notes for the EDK2 snapshot or build tag. If the OVMF binary identifies a build that predates the advisory’s affected cutoff, assume potential exposure and remediate.
- Extract OVMF or firmware binary and search for symbol names or strings referencing IScsiDxe/IScsiProto.c to confirm the module is present.
- Where SBOMs are available, search for NetworkPkg/IScsiDxe and identify the commit or release versions. Map those to the advisory’s affected range from the Github advisory.
Timelines, patch status and vendor coordination (what to expect)
- The Tianocore advisory for GHSA‑8522‑69fh‑w74x was published March 14, 2025 and referenced affected EDK2 snapshots (<=202502) with detailed code excerpts; at publication the advisory noted “Patched versions: None,” meaning downstream vendors were expected to produce firmware updates. Administrators should treat the upstream advisory as the canonical technical description and track vendor patch releases for their platform.
- Public trackers (OSV, CVE aggregator sites) updated their records shortly after the advisory — confirm the CVE record timestamp (March 14, 2025) when documenting your remediation timeline.
- Microsoft’s VEX/CSAF rollout to other Microsoft SKUs is ongoing. Expect MSRC to expand attestations to additional product families over time; until then, operators own the verification burden for non‑attested artifacts.
Final assessment and recommended posture
CVE‑2025‑2295 is a real and verifiable issue in EDK2’s iSCSI DXE implementation that enables remote memory exposure via crafted iSCSI R2T PDUs. The upstream Tianocore advisory provides a clear technical description and proof points that independent aggregators reproduce. Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” should be read exactly as intended: an authoritative inventory result for Azure Linux, published as machine‑readable VEX/CSAF metadata and actionable for those customers. It is not a categorical statement that no other Microsoft product contains the same component; absence of an MSRC attestation for other Microsoft artifacts is not proof of absence and must be treated as an unknown until verified. Organizations must therefore combine vendor attestations with artifact‑level inventory, SBOM review and binary/firmware scanning to reach full assurance across their estate.Operational priorities are clear:
- Immediate: patch attested Azure Linux images, block or isolate untrusted iSCSI targets, and monitor for anomalous iSCSI traffic.
- Short term: inventory all Microsoft‑supplied artifacts you run (WSL kernels, linux‑azure packages, Marketplace images), ingest MSRC VEX feeds, and request SBOM/attestations from vendors.
- Medium term: harden firmware and VM image pipelines to ensure EDK2 snapshots are tracked, SBOMs are produced, and firmware/OVMF images are scanned as part of CI/CD.
CVE‑2025‑2295 underscores a persistent reality of modern software supply chains: the same upstream open‑source component can appear in multiple products and images, and vendor attestations are a powerful tool — but they are most useful when paired with artifact‑level verification to close the long tail of unknowns.
Source: MSRC Security Update Guide - Microsoft Security Response Center
