CVE-2022-28737 Shim Overflow: Azure Linux Attestation and Exposure

A subtle overflow in a widely used UEFI helper — the shim bootloader’s handle_image() routine — reappeared in headlines after CVE-2022-28737 was published, and Microsoft’s short advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” has prompted a single, practical question from many admins: is Azure Linux the only Microsoft product that ships the vulnerable shim code? The short, factual answer is: No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the vulnerable shim component, but that attestation is a product‑scoped inventory statement, not proof that other Microsoft artifacts cannot also carry the same code. Multiple independent downstream advisories and upstream CVE records show the flaw in shim and the distributions that patched it; Microsoft’s wording reflects their current inventory position and their commitment to expand machine-readable attestations where appropriate.

---

Background / Overview​

shim is a tiny, distribution-shipped UEFI first-stage bootloader used across many Linux distributions to bridge the platform firmware’s Secure Boot enforcement and the distribution’s signed kernel/bootloader chain. It exists precisely to enable Linux distributions to boot on Secure Boot platforms by acting as a small, trusted loader that can validate a downstream GRUB or kernel loader. The component is packaged by major distributions (Red Hat, Ubuntu, SUSE and others) and appears in vendor kernel/installer images and virtual-machine images where an EFI boot chain is used.
CVE-2022-28737 is a code‑safety defect in shim’s image handling: the vulnerable function, handle_image(), trusts the SizeOfRawData values present in EFI section headers when copying section contents into memory. If a crafted EFI binary supplies malicious or deliberately oversized SizeOfRawData entries, memcpy-like operations can write past the intended buffer and corrupt adjacent memory, opening the door to out‑of‑bounds writes and potential arbitrary code execution in the pre‑OS boot context. The defect appears in shim versions prior to the patched upstream release in the 15.x series; maintainers and downstream vendors published updates after the defect became public.
Why that matters to defenders: the boot chain is executed earlier than kernel or userland defenders. A successful exploit that injects code at the shim/EFI stage can persist across OS reinstalls, evade many endpoint protections, and turn the system’s firmware/boot stage into the attacker’s beachhead.

---

The vulnerability in plain terms​

• The code reads a section header field (SizeOfRawData) supplied by the EFI binary and uses it as the copy length for the binary’s section data.
• There is insufficient validation of that length against the destination buffer bounds.
• An attacker who can cause shim to load a crafted EFI image (for example by placing one on the EFI System Partition, booting from removable media, or otherwise controlling a boot-time payload) can trigger an out‑of‑bounds write.
• Depending on memory layout and available primitives, that write can corrupt function pointers, dispatch tables, or return addresses in the pre‑OS code path — enabling code execution before the operating system begins.

The technical takeaway: the vulnerability is straightforward and serious in the boot-time threat model. However, exploitation is constrained by attack surface and access requirements — attackers typically need the ability to supply or replace EFI images or persuade the platform to boot a crafted image. In cloud or multi‑tenant contexts the attack flow differs from bare‑metal contexts; practical exploitation often requires local control over image contents, physical access, or misconfiguration that allows untrusted boot images.

---

Microsoft’s advisory: what it actually says​

Microsoft’s Security Response Center (MSRC) entry for related Linux-kernel and userland CVEs has used a short, repeatable phrase: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” Microsoft has also stated a programmatic commitment to publish machine‑readable CSAF/VEX attestations (they began that work in October 2025) and to update CVE records if they identify impact to additional Microsoft products. That is an operational inventory statement about what Microsoft has checked and attested to today, not a categorical claim that other Microsoft products definitely do not include the same upstream component.
Put differently: Microsoft is telling customers which of its products the company has confirmed contain the vulnerable component — and promising to expand that mapping if further exposures are found. It is not promising an exhaustive proof that every Microsoft image or artifact lacks the component unless explicitly attested.
This is a subtle but crucial distinction for incident responders and procurement/security teams evaluating enterprise exposure.

---

Is Azure Linux the only Microsoft product that includes shim?​

Short answer again, with evidence: No — not necessarily.

• Authoritative inventories: Microsoft has published an attestation for Azure Linux (CBL‑Mariner / Azure Linux images) and said it will update the CVE mapping if additional products are found to include the component. That is an honest, authoritative statement for Azure Linux and useful for Azure customers.
• But absence of attestation ≠ absence of exposure: Microsoft ships — or historically has shipped — a variety of Linux artifacts inside the company’s product mix (kernel builds, VM images, marketplace images, appliance images, and internal base images). Any of those artifacts that were assembled from upstream tree snapshots or distribution packages that include shim could technically carry the vulnerable binary until patched. Public MSRC disclosures for other CVEs have followed the same pattern: Azure Linux is attested first, and Microsoft updates the mapping when additional product-level carriers are found.

Consequence for defenders: treat Microsoft’s attestation as an important starting point, not a complete elimination of risk. If you operate or depend on other Microsoft-delivered Linux artifacts — for example, custom Azure Marketplace images, embedded Linux appliances from Microsoft, or distributions used inside proprietary appliances — those artifacts should be inventoried independently.

---

How to check whether a Microsoft product or image is carrying shim​

If your environment relies on Microsoft-supplied Linux artifacts, here are practical, prioritized steps to determine presence and exposure:

• Inventory the artifacts you run that were supplied by Microsoft (Azure Marketplace images, managed images, WSL kernels/images that Microsoft distributes, appliance images).
• For each artifact, check the package list or installed files for the shim package:
• On RPM systems: run rpm -qa | grep shim and rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' shim to get exact versions.
• On DEB systems: run dpkg -l shim* or apt list --installed | grep shim.
  These commands reveal whether shim is installed and which version — if the version is older than the patched threshold (shim 15.6/15.7 depending on downstream packaging) you have a carrier. (Adjust commands for automation and compliance scanning.)
• Check shipped SBOMs and VEX/CSAF attestations: Microsoft has committed to machine-readable VEX/CSAF disclosures; examine the vendor-provided SBOM or attestation for the image in question. If Microsoft has not published an attestation for the product you run, request one through your Microsoft support channels or your account representative.
• For cloud images: examine the mounted EFI System Partition (if accessible), or the image build recipe (in Azure Shared Image Gallery or Marketplace metadata) for included boot packages. Where possible, build or pull a copy of the image and run the package checks above.
• If you manage hardware fleet images or vendor-supplied appliances, request the vendor’s SBOM and specific package-level evidence that shim is absent or patched.

Why these steps are necessary: Microsoft’s attestation only tells you about Azure Linux images Microsoft has explicitly reviewed; it does not automatically cover every image or custom artifact you might run that originated at Microsoft or was derived from Microsoft-supplied components.

---

Attack scenarios that materially matter to Microsoft customers​

Not all environments face the same risk from CVE-2022-28737. Consider these broad scenarios:

• Bare‑metal desktops and servers with physical access or removable-boot permissions: higher risk, because an attacker with physical access or the ability to place a crafted EFI binary on the firmware-visible storage can attempt to boot the crafted image. The exploit’s pre‑OS nature elevates severity in this model.
• Cloud VMs (Azure): moderate to low remote risk in default configurations. Most cloud VM models do not permit arbitrary remote replacement of the platform boot path without prior control of the guest image or hypervisor controls. However:
• If an attacker gains write access to an image or to the EFI System Partition via a compromise of your storage account or image build pipeline, they could create a crafted image that the VM subsequently boots — this is an operational risk scenario, not a pure remote code execution vector.
• Managed services that allow customers to upload custom images will need to ensure image validation and patching policies.
• Virtual appliances and marketplace images: mixed risk — these may include shim in the image and can be patched by image owners; check the specific Marketplace image vendor or the image’s SBOM.

Bottom line for cloud and enterprise: the highest-value operational response is inventory + patching of carrier images rather than assuming a remote, unauthenticated exploit will happen without other control failures.

---

Patching and mitigation guidance​

• Update shim to a patched upstream release: distributions released fixed shim packaging (examples: Red Hat, Ubuntu, SUSE have shipped fixed versions in their security advisories). Identify the exact patched package version for your distribution (for example, many distros shipped fixes in the 15.7+ line or equivalent downstream builds).
• For Azure Linux customers: follow Microsoft’s guidance and apply the distribution updates Microsoft publishes for Azure Linux images; MSRC attestation indicates Microsoft has identified Azure Linux images as carriers and will publish VEX/CSAF attestations where appropriate.
• Minimize exposure to untrusted boot images:
• Enforce tight controls on who can upload/modify VM images and who can mount or edit the EFI System Partition.
• Disable or restrict booting from removable media where possible in managed fleets.
• Harden image build pipelines: minimize the number of accounts that can publish images and require pipeline signing/approval for image promotions.
• Use Secure Boot policies that restrict allowed signers, and complement Secure Boot with measured/verified boot processes where available.
• For environments that cannot apply updates immediately, consider compensating controls: restrict physical access, lock down VM image management, and increase monitoring of image and storage account activity that could indicate tampering.

---

Practical incident response priorities (ordered)​

• If you run Azure Linux images, apply the vendor‑provided updates immediately — that is the highest priority because Microsoft has confirmed the carrier status for the product.
• Inventory other Microsoft-supplied images and appliances that your organization consumes; check for shim packages and version strings using automated package inventory tooling.
• For any image found to include a vulnerable shim version, schedule an image rebuild with patched packages and replace the running instances after validation.
• Review and tighten image-management and storage permissions to ensure an adversary cannot trivially replace or inject EFI images.
• If you suspect EFI-stage compromise (evidence of pre-OS tampering), engage forensic specialists — persistent boot‑stage implants are among the hardest incidents to remediate cleanly without re-imaging hardware and re-installing firmware-level components.

---

Why Microsoft’s phrasing is sensible — and where it leaves customers with work to do​

Microsoft’s brief attestation format — asserting the products it has checked — is operationally useful and transparent: it tells customers exactly which of Microsoft’s published product images contain the vulnerable library today. It also signals a change in Microsoft’s approach to supply-chain transparency by committing to machine-readable CSAF/VEX attestations. But it is not a statement of exclusivity: the fact that only Azure Linux is listed today is not a technical guarantee that other Microsoft‑delivered artifacts do not include the component; it is only a reflection of what Microsoft has completed inventory work for and publicly attested. Security teams must therefore combine vendor attestations with their own inventories and verification steps.
This pattern is not unique to Microsoft. Many vendors begin supply-chain transparency by publishing attestations for a single product family or a prioritized set of artifacts, and expand the mapping over time. The defensible practice for large organizations is to treat those vendor attestations as authoritative for the product named and as incomplete for other products until those products are attested.

---

Recommendations for product owners and for Microsoft​

For product owners (customers and partners):

• Don’t rely solely on a vendor’s single‑product attestation; run local SBOM/packaging scans against the actual images you run in production.
• Integrate packaging checks into your CI/CD and image‑release pipelines to catch vulnerable shim or other boot components before images are published.
• Demand machine‑readable attestations (CSAF/VEX) for any third‑party or vendor images you consume, and automate ingestion of those attestations into your patch orchestration tools.

For Microsoft (and other large vendors):

• Continue and accelerate the CSAF/VEX rollout across more Microsoft artifacts and product families beyond Azure Linux.
• Provide searchable SBOMs and clear package versions for Marketplace images so customers can automate verification.
• Where possible, publish targeted build metadata for kernel and bootloader packaging in images that make it trivial for operators to verify presence or absence of specific upstream components.

The industry-level win here is predictable: vendors that publish comprehensive, machine-readable attestations reduce customer effort and shrink mean time to remediate in real incidents.

---

Closing assessment​

CVE-2022-28737 is a real, boot-stage memory-safety flaw in the shim project that was fixed in downstream packaging and has been patched by major Linux distributors. Microsoft’s zure Linux** as a product that “includes this open‑source library and is therefore potentially affected” is an important, actionable attestation for customers who run Azure Linux images — but it must not be read as a global guarantee that no other Microsoft product carries the component. Customers and operators should treat the attestation as a starting point: verify the images you run, patch or rebuild any carriers, and harden image/boot controls to reduce the risk that an attacker can deliver a crafted EFI payload to an environment that still runs vulnerable shim code.
In practical terms:

• If your estate includes Azure Linux images: prioritize applying the distributor’s shim updates immediately.
• If your estate uses other Microsoft-supplied images or images whose provenance you cannot fully confirm: perform an inventory scan for shim and require a VEX/CSAF attestation or SBOM before trusting the image in production.

The incident underscores two enduring lessons for enterprise defenders: the boot chain is an exploitable, high-value target; and inventory plus automation remains the single best defense against supply‑chain and packaging defects that move from upstream projects into shipped products.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center