CVE-2025-22026: Azure Linux attestation and how to vet other Microsoft artifacts

Microsoft’s wording is precise but incomplete: for CVE‑2025‑22026 the company has publicly attested that Azure Linux includes the affected upstream component and is therefore potentially affected, but that attestation is a product‑level inventory statement — not proof that no other Microsoft product can or does contain the vulnerable code.

Background / Overview​

CVE‑2025‑22026 is a Linux kernel fix in the NFS server code: nfsd: don't ignore the return code of svc_proc_register. The bug stems from nfsd_proc_stat_init ignoring the return value from svc_proc_register; if procfile creation fails, the kernel later warns when it tries to remove the entry. The upstream remedy changes nfsd_proc_stat_init so it returns and checks the same pointer/errno semantics as svc_proc_register, and adjusts nfsd_net_init to abort construction on failure. The technical details and published fixes are available in standard vulnerability trackers and distribution advisories. Why this matters operationally: the defect is a robustness/availability issue (kernel WARNs and potentially OOPS/panic during cleanup), not a remote code execution or immediate data‑exfiltration primitive. That said, kernel warnings and accidental oopses are high‑impact in production and multi‑tenant environments, where availability and isolation are critical. Multiple distributors (Debian, Ubuntu, Oracle, SUSE, Amazon Linux) have mapped the upstream commits to packaged kernel updates and published fixes.

---

The Microsoft statement — what it actually says​

Microsoft’s update guide entry for CVE‑2025‑22026 (the page quoted by the user) uses the phrase that “Azure Linux includes this open‑source library and is therefore potentially affected” and notes Microsoft began publishing machine‑readable CSAF/VEX attestations (October 2025) and will update the CVE if additional Microsoft products are identified. This reflects Microsoft’s new, phased VEX/CSAF rollout: start with a single product family (Azure Linux) and publish authoritative, machine‑readable attestations for that family before expanding coverage. The MSRC blog describing the program explicitly explains this phased approach. Two key points to read in that wording:

• Authoritative scope for the named product: when Microsoft says Azure Linux includes a component, that is an authoritative inventory attestation for Azure Linux images and kernels that Microsoft maintains. Operators running Azure Linux should treat the attestation and any VEX/CSAF metadata as the canonical remediation signal for those images.
• Not a universal exclusion: the attestation is not a categorical statement that no other Microsoft products include the same upstream code. Microsoft’s commitment to “update the CVE if impact to additional products is identified” is procedural: the company will expand the product mapping as it completes additional inventory and SBOM work. Absence of a product in Microsoft’s VEX output is absence of attestation, not evidence of absence of code.

---

Short answer to the user’s question​

• Is Azure Linux the only Microsoft product that includes the open‑source library and is therefore potentially affected by CVE‑2025‑22026?
• Short factual answer: Azure Linux is the only Microsoft product Microsoft has publicly attested as including the affected component at the time of the advisory.
• Operationally correct answer: No — that attestation does not mean other Microsoft products are guaranteed to be unaffected. Any Microsoft image, kernel artifact, appliance, curated container, or binary that embeds the same upstream kernel code or a kernel built from the vulnerable commits could be a carrier until explicitly verified or updated. Treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux, and treat other Microsoft artifacts as “unknown” until they are inventoried or attested.

---

Why vendors publish attestations one product at a time​

Large vendors maintain many images, containers, on‑device artifacts and internal builds. Publishing accurate, machine‑readable attestations (CSAF and VEX) requires reliable inventory data (SBOMs, build provenance, package manifests) for each product family. A phased rollout reduces time to publish actionable data for at least one product family (Azure Linux) while the vendor completes artifact‑level inventory for the rest of its product portfolio. This is a pragmatic transparency model — useful and actionable, but inherently partial until the vendor finishes scanning all artifacts.

---

Technical verification: how to confirm whether your Microsoft artifacts are affected​

The only reliable way to determine whether a given Microsoft product image or artifact is affected is artifact‑level verification. The presence of a vendor attestation for Azure Linux is a strong indicator for those images, but you must confirm for each other Microsoft image you run.
Practical checklist (quick, actionable):

• Identify images and artifacts you run that are Microsoft‑published:
• Azure Marketplace VM images and snapshots
• Azure Linux (the attested family — patch immediately)
• Curated Azure container images (Azure ML, ACPT, curated runtime images)
• WSL2 kernel images (Windows Subsystem for Linux)
• Marketplace appliances and Microsoft‑published container images
• Any Microsoft agents, installers, or appliances that include a Linux rootfs
• For each image/artifact, determine whether it runs a kernel including nfsd and whether the kernel maps to an upstream commit or fixed package:
• On a running Linux host: uname -r ; zcat /proc/config.gz | grep -i nfs ; lsmod | grep nfsd ; grep -i nfs /boot/config-$(uname -r)
• For container images: inspect the image manifest or run the image: docker run --rm -it <image> uname -r ; dpkg -l | grep linux-image ; rpm -qa | grep kernel
• For WSL images: check the WSL kernel configuration published by Microsoft or the kernel shipped with your WSL instance.
• Map the kernel/package to vendor advisories and upstream commits:
• Use distribution trackers (Debian, Ubuntu, SUSE, Oracle, Amazon Linux) to find fixed package versions and CVE mappings. If your kernel package version is listed as fixed by the distro advisory, apply that package.
• If you manage images centrally, automate detection:
• Ingest vendor CSAF/VEX files when they are published for Azure Linux.
• Use SBOM consumers and image scanners to detect the presence of affected kernel packages or static binaries linked against the kernel.
• Use image provenance metadata (build tags, base image IDs) to map older images to vulnerable base kernels.

---

Commands and checks operators can run now​

• Check whether nfsd is present and loaded:
• systemctl status nfs-server
• lsmod | grep nfsd
• ps aux | grep nfsd
• Check kernel version and config:
• uname -a
• zcat /proc/config.gz | grep -i nfs
• grep -i nfs /boot/config-$(uname -r)
• Inspect image contents quickly (containers):
• docker pull <image>
• docker run --rm <image> cat /proc/version
• docker run --rm <image> sh -c 'uname -r && grep -i nfs /boot/config-$(uname -r) || true'
• Map to vendor advisories:
• Consult distribution CVE trackers (Debian, Ubuntu, SUSE) to find which packaged kernel versions contain the upstream fix. Use those package names/versions in your patching plan.

---

Remediation guidance (practical, prioritized)​

• Immediate (0–48 hours)
• Treat Azure Linux images as in‑scope: apply Microsoft’s Azure Linux updates and rebuild/publish any derived images. Microsoft’s VEX/CSAF attestation and the Azure Linux advisory are the canonical starting point for those images.
• For other Microsoft images you run (Marketplace images, curated containers, WSL kernels), run the artifact checks listed above to determine exposure.
• If an image or host is confirmed to contain the vulnerable kernel code, schedule a kernel update, reboot and validate.
• Short term (48 hours – 2 weeks)
• Prioritize internet‑facing, multi‑tenant, and CI/worker images for patching and rebuilds.
• For long‑lived images that are hard to rebuild immediately, apply compensating controls: isolate the image, restrict who can run workloads on it, and restrict access to nfs services until patched.
• Medium term (2–8 weeks)
• Automate SBOM ingestion and VEX/CSAF consumption so future vendor attestations are machine actionable.
• Rebuild and re‑release any curated images, containers, or appliances that were derived from the vulnerable base image.
• Long term
• Integrate vendor VEX/CSAF feeds into your patch management and orchestration systems so product attestation changes automatically drive triage workflows.
• Adopt image signing and provenance rules to prevent redeploying old images that carry vulnerable kernels.

---

How to interpret Microsoft’s promise to “update the CVE” if more products are identified​

Microsoft’s pledge to update the CVE/VEX record if additional Microsoft products are discovered is a process guarantee: as Microsoft’s inventory and SBOM coverage expands across product lines, it will add product‑level attestations for any additional Microsoft artifacts that include the vulnerable component. That does not mean those other products are currently known to be clean — it means Microsoft will publish a change when it knows more. Until such attestations appear, operators should assume non‑Azure Linux Microsoft artifacts are in an unknown state and verify them directly.

---

Cross‑checks and independent confirmation​

To avoid single‑vendor dependency in triage, cross‑check three classes of source:

• Upstream and canonical CVE records (NVD, MITRE): confirm the technical description and upstream commit references.
• Distribution security trackers (Debian, Ubuntu, SUSE, Oracle, Amazon Linux): confirm whether the distro/kernel package you run is flagged vulnerable or fixed and find the package version to install.
• Vendor attestations (Microsoft VEX/CSAF for Azure Linux) plus vendor blogs outlining the VEX rollout approach — use these attestations for the vendor‑named products, but do not extrapolate them beyond the named artifacts without verification.

Cross‑referencing these three categories reduces the chance of mistaken assumptions and makes it possible to construct a defensible, auditable remediation path.

---

Risk analysis: strengths and residual risks​

Strengths of Microsoft’s VEX/CSAF approach

• Faster, machine‑readable triage for Azure Linux customers: automated tooling can consume VEX files to mark images and automate patch workflows.
• Clear product scope: the attestation gives a precise starting point for Azure Linux remediation rather than ambiguous advisory prose.

Residual risks and blind spots

• Partial inventory at publication: until Microsoft finishes scanning its entire product portfolio, some Microsoft‑published artifacts may still carry the vulnerable code without being attested. Treat absence of attestation as “unknown,” not “safe.”
• Static or embedded artifacts: statically built binaries, embedded kernels in appliances, and baked images may carry the vulnerable code even if package managers do not list a vulnerable kernel package. These often require rebuilds rather than simple package updates.
• Long tail of images and marketplace artifacts: organizations may have old snapshots, cached images, or partner marketplace images that are not actively patched; these are typical sources of residual exposure in cloud estates.

---

Recommended detection & monitoring additions​

• Add SIEM rules to detect kernel WARNs or repeated NFS server failures: search for kernel messages that include nfsd, svc_proc_register, or WARN_ON traces that mention /proc removal errors.
• Add image scanning rules to flag any image whose kernel package version predates the distro’s fixed version for CVE‑2025‑22026.
• Automate SBOM ingestion and tag your inventory to show “Azure Linux — VEX attested” vs “other Microsoft images — verify artifact.”
• Add a periodic job to reconcile Microsoft VEX/CSAF feeds with your image inventory and to escalate any images that transition from Unknown to Known Affected or Fixed.

---

Practical example: mapping patch sources​

• If a host is running a Debian or Ubuntu kernel version that distribution trackers list as vulnerable for CVE‑2025‑22026, follow the distro’s published fixed package version and upgrade to that kernel package and reboot. Confirm that the package changelog references the upstream stable commit.
• If a cloud image is Azure Linux (Microsoft‑published), consume Microsoft’s VEX/CSAF record for CVE‑2025‑22026 and follow the Azure Linux advisory for updates and image replacements. Microsoft’s VEX attestation is the canonical signal for Azure Linux.

---

Conclusion​

Microsoft has done two useful things: it publicly attested that Azure Linux includes the component that maps to CVE‑2025‑22026, and it published a transparency roadmap (CSAF/VEX) that begins with Azure Linux and will expand to other products over time. That makes Azure Linux the one Microsoft product to treat as confirmed in‑scope at present.
However, the practical and operational reality is that Azure Linux being attested does not prove that no other Microsoft artifact contains the same vulnerable kernel code. Any Microsoft‑published image, WSL kernel, appliance, or container that embeds or ships a kernel built from the vulnerable commits could be a carrier until it is verified or patched. The defensible operational posture is:

• Treat the Microsoft Azure Linux attestation as authoritative for Azure Linux and patch those images immediately.
• Perform artifact‑level verification for all other Microsoft images and kernels you run (inventory, inspect, scan).
• Automate SBOM / VEX consumption and reconcile vendor attestations against your inventory so future attestations drive triage automatically.

Apply the vendor or distribution kernel updates listed in the distro advisories (Debian, Ubuntu, Oracle, SUSE, Amazon Linux) and validate remediation by confirming the updated kernel packages or patched image rebuilds are in production. This combined approach — vendor attestation for Azure Linux, artifact‑level verification elsewhere, and automation of VEX/CSAF feeds into patch pipelines — provides the most reliable path to close CVE‑2025‑22026 across cloud and on‑prem estates.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center