Microsoft’s public attestation that Azure Linux includes the open‑source kernel component tied to CVE‑2025‑21885 is accurate — but it is a product‑scoped inventory statement, not a universal technical guarantee that no other Microsoft product can include the same vulnerable code. Azure Linux is the only Microsoft product Microsoft has publicly validated and published as “potentially affected” for this CVE so far; Microsoft has explicitly committed to update its CSAF/VEX mapping if additional Microsoft products are later found to ship the same upstream component.
CVE‑2025‑21885 is a Linux kernel vulnerability affecting the RDMA bnxt_re driver (Broadcom/Broadcom-derived RDMA code paths). The defect concerns how page details are set for Shared Receive Queues (SRQs) that are created by kernel consumers, and manifests as a kernel panic (divide error) in NVMe target configurations with SRQs enabled. The vulnerability was publicly disclosed on March 27, 2025 and recorded in the NVD. The operational impact is primarily availability: hosts that exercise the affected driver path (for example: RDMA-enabled hosts using bnxt_re with NVMe target + use_srq) can crash with an OOPS/panic, producing denial‑of‑service conditions for workloads running on that host. Multiple distro and vendor advisories (Debian, Ubuntu, Oracle, Amazon Linux, Red Hat) have incorporated the upstream fix and mapped it into their packaged kernels. Microsoft’s public messaging around this and similar kernel CVEs follows its recently introduced machine‑readable attestation program: Microsoft publishes CSAF/VEX attestations starting with Azure Linux (the company’s maintained Linux distribution) and uses those attestations to state which Microsoft product artifacts are known affected, not affected, under investigation, or fixed. The company has said it will expand those attestations to other Microsoft products as its internal inventory work completes.
Why that nuance exists:
Action summary (one line): If you run Azure Linux images, apply Microsoft’s Azure Linux kernel update; if you run other Microsoft‑supplied Linux artifacts (WSL, Marketplace images, custom appliances), verify bnxt_re presence and the kernel build before assuming they are unaffected — and track Microsoft’s VEX/CSAF updates for any expansion of the product mapping.
End of report.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑21885 is a Linux kernel vulnerability affecting the RDMA bnxt_re driver (Broadcom/Broadcom-derived RDMA code paths). The defect concerns how page details are set for Shared Receive Queues (SRQs) that are created by kernel consumers, and manifests as a kernel panic (divide error) in NVMe target configurations with SRQs enabled. The vulnerability was publicly disclosed on March 27, 2025 and recorded in the NVD. The operational impact is primarily availability: hosts that exercise the affected driver path (for example: RDMA-enabled hosts using bnxt_re with NVMe target + use_srq) can crash with an OOPS/panic, producing denial‑of‑service conditions for workloads running on that host. Multiple distro and vendor advisories (Debian, Ubuntu, Oracle, Amazon Linux, Red Hat) have incorporated the upstream fix and mapped it into their packaged kernels. Microsoft’s public messaging around this and similar kernel CVEs follows its recently introduced machine‑readable attestation program: Microsoft publishes CSAF/VEX attestations starting with Azure Linux (the company’s maintained Linux distribution) and uses those attestations to state which Microsoft product artifacts are known affected, not affected, under investigation, or fixed. The company has said it will expand those attestations to other Microsoft products as its internal inventory work completes. Technical summary of CVE‑2025‑21885
What goes wrong (short technical view)
- The vulnerability is in the bnxt_re RDMA driver’s SRQ initialization path used by kernel consumers (for example an in‑kernel NVMe target).
- Page size / page shift details are set for SRQs created from userspace, but kernel‑created SRQs were missing or receiving incorrect page metadata.
- When the code uses the missing/incorrect page information in arithmetic, it can hit a divide/shift error that causes an OOPS/panic in the kernel. The crash trace published with the advisory shows the failure originating from bnxt_qplib_alloc_init_hwq → bnxt_qplib_create_srq → bnxt_re_create_srq.
Exploitability and impact
- Attack surface: Local by default — an attacker would need the ability to trigger kernel SRQ creation or to manipulate an environment where kernel SRQs are built (for example, misconfigured NVMe target stacks, RDMA testbeds, or multi‑tenant RDMA‑capable hosts).
- Primary effect: availability (kernel crash / system reboot). There is no widely published proof‑of‑concept demonstrating remote code execution at disclosure time; the known outcome is an OOPS/panic and service outage.
- Severity: vendors and trackers mark the issue as medium (CVSS in the mid‑5 range, operational impact classified as Availability:C). Prioritize hosts where the bnxt_re driver and SRQ usage are present.
What Microsoft actually said — reading the MSRC message precisely
Microsoft’s public Security Update Guide and its accompanying VEX/CSAF practice contain the phrasing quoted by the user: that “Azure Linux includes this open‑source library and is therefore potentially affected” and that Microsoft “will update the CVE to reflect this” if other products are found to ship the same component. That wording is deliberate and procedural: it reports the outcome of Microsoft’s inventory for the Azure Linux product family and promises to expand published mappings as additional inventory work completes. Key operational takeaways from Microsoft’s wording:- Authoritative for Azure Linux: The statement is the canonical signal for customers running Microsoft‑published Azure Linux images and kernels; those customers should treat Microsoft’s VEX/CSAF attestations for Azure Linux as definitive for that product family.
- Not an exclusion of all other Microsoft products: A product‑scoped attestation is not the same as a global “only this product” guarantee. Microsoft explicitly commits to update the CVE/VEX mapping if additional Microsoft artifacts are discovered to include the vulnerable upstream code. In practice, vendors commonly publish phased attestations (start with one product family), which speeds disclosure for users of that product but leaves other product inventories to be validated subsequently.
Is Azure Linux the only Microsoft product that includes the vulnerable library?
Short, evidence‑backed answer: No — not necessarily, but Azure Linux is the only Microsoft product Microsoft has publicly attested to include the affected bnxt_re code as of the published advisory. That distinction is crucial.Why that nuance exists:
- Product‑scoped attestations: Microsoft’s VEX/CSAF rollout explicitly began with Azure Linux in October 2025 as a phased program. The publications therefore reflect where Microsoft has finished its inventory and validation work, not a blanket inventory of every Microsoft image, appliance, or kernel build.
- Kernel artifacts are per‑build properties: Whether a Microsoft product contains the vulnerable code depends on how its kernel was built — CONFIG_ options, module selection, backports and vendor patches vary across artifacts. Two Microsoft products can ship kernels from related trees yet differ in which drivers and features are compiled in. That means absence of a VEX mapping for a product is not proof of absence of the vulnerable code*; only a host‑level inspection (kernel config, loaded modules, package changelog, or SBOM/VEX evidence) can confirm.
- Microsoft ships multiple Linux‑facing artifacts that could, depending on build provenance, carry the bnxt_re driver:
- Azure Linux distribution images and their kernel packages (explicitly attested).
- linux‑azure kernels or other Microsoft‑built kernel packages used by Azure VM images.
- Azure Marketplace images and third‑party partner images that may package different kernels.
- Windows Subsystem for Linux (WSL2) kernels distributed by Microsoft (WSL kernels are separate artifacts and may or may not include specific drivers).
- Container base images and curated node images (AKS/AKS node images) that may embed kernel packages or kernel modules during image construction.
Cross‑verification: corroborating the technical facts (multiple independent sources)
To verify the technical description and distribution mapping, consult multiple independent sources:- NVD CVE entry for CVE‑2025‑21885 gives the vulnerability summary and indicates the kernel panic / bnxt_re trace.
- Vendor distribution advisories (Oracle Linux, Amazon Linux/ALAS, Debian/Ubuntu, Red Hat) published matching kernel fixes and status mappings that confirm the upstream kernel patch and show which packaged kernels were updated. These advisories independently corroborate the technical nature (SRQ page detail / kernel panic) and the remediation path.
- Security trackers and vulnerability databases (Rapid7, Snyk, Wiz) summarize exploitability and provide CVSS/operational context consistent with the NVD description. Using at least two independent trackers reduces the risk of a single‑source misinterpretation.
Practical verification: how to confirm whether your Microsoft‑supplied artifacts are affected
Operators must verify hosts individually. Use the following steps to determine exposure for any given host, VM image, or appliance.Quick inventory and detection checklist
- Confirm whether the bnxt_re (or bnxt) modules are present or built in:
- Run: uname -r to get the running kernel version.
- Check loaded modules: lsmod | grep -E 'bnxt|bnxt_re|bnxt_en'
- Inspect module details: modinfo bnxt_re (if present)
- Search kernel logs for the crash signature:
- dmesg | grep -i 'bnxt_re|bnxt_qplib|create_srq|divide error|Oops'
- journalctl -k | egrep -i 'bnxt|srq|divide error|bnxt_qplib'
- Confirm package changelog maps to fixed upstream commits:
- Debian/Ubuntu: apt changelog linux-image-$(uname -r) or check the distro security tracker.
- RHEL/Oracle/Amazon: check vendor advisories and package changelogs for the CVE or the upstream commit IDs referenced in NVD.
- For images and appliance artifacts:
- If you run a Microsoft‑published Azure VM image or Azure Marketplace VM, check the VEX/CSAF mapping Microsoft published for that CVE and the specific SKU(s) you run.
- For WSL2 or custom kernels, inspect the shipped kernel binary’s config (zcat /proc/config.gz | grep CONFIG_BNXT) or the WSL kernel repo in your build pipeline.
Commands (example)
- lsmod | grep bnxt
- sudo modinfo bnxt_re
- dmesg | grep -i 'bnxt_qplib_create_srq'
- zcat /proc/config.gz | egrep 'BNXT|RDMA|SRQ'
Remediation & mitigation guidance
- Primary remediation: apply the upstream kernel patch or vendor‑packaged kernel update that contains the bnxt_re fix. Distributions have mapped the upstream commit into stable kernels; apply the vendor security update and reboot into the patched kernel.
- For Microsoft Azure Linux customers: follow Microsoft’s VEX/CSAF guidance and upgrade to the Azure Linux kernel package version Microsoft marks as Fixed in its attestation for the CVE. Microsoft’s VEX attestation files and the MSRC blog explain the mapping and release guidance.
- Short‑term mitigations when patching cannot be immediate:
- Remove/unload the bnxt_re module if the hardware/drivers are not needed on that host. Note: unloading kernel drivers can disrupt active networking/RAID/RDMA paths — do this only when safe.
- Isolate RDMA hosts from untrusted tenants and restrict who can create or manipulate NVMe target configurations that might call the vulnerable path.
- Use host hardening and least‑privilege controls to prevent untrusted users from interacting with RDMA/NVMe target subsystems.
- For appliance vendors and custom kernel builders:
- Merge the upstream commit referenced by the NVD into your kernel tree, rebuild, test under representative RDMA/NVMe workloads, and publish an updated image or kmod package.
- If you ship static binaries or statically‑linked drivers, replace the binary with one rebuilt against the patched kernel tree.
Strengths, risks, and operational analysis
Strengths in the overall response
- The bug was fixed upstream in a small, surgical kernel change, which eases distribution backporting and reduces regression risk. Multiple distributions and vendors have already shipped fixes.
- Microsoft’s CSAF/VEX program — started as a phased rollout with Azure Linux — improves transparency and gives customers machine‑readable attestations to automate triage against specific product SKUs. That is a practical gain for operators who run Azure Linux images.
Residual risks and caveats
- Microsoft’s attestation indicates what has been validated for Azure Linux only; it is not a proof that other Microsoft artifacts (WSL kernels, other Azure VM image families, Marketplace images, or partner appliances) do not carry the same bnxt_re code. Operators must verify each artifact they run. Treat absence of an attestation as unknown, not safe.
- Long tails exist: third‑party Marketplace images, vendor‑forked kernels, custom appliance builds, or static binaries may lag on backports and continue to ship vulnerable code even after mainstream distribution fixes are available. Target these long tails with inventory and vendor engagement.
- Detection gap: kernel crashes can be noisy but intermittent; automated crash‑suppression or aggressive log rotation may make it harder to detect historical OOPS events. Preserve crash logs and vmcores when possible to aid triage.
Recommended operational checklist (compact)
- Inventory: enumerate all Linux hosts (VMs, containers with privileged kernels, WSL2, appliance images) and find those with bnxt_re present. (lsmod, modinfo, uname).
- Consult Microsoft’s VEX/CSAF attestations for the CVE and map them to your Azure Linux SKU(s). Treat the attestation as authoritative for those SKUs.
- Cross‑check with NVD and distro advisories to locate the vendor package that contains the upstream fix.
- Patch: apply vendor‑supplied kernel updates or rebuild and deploy patched kernel/artifacts; reboot into patched kernels.
- Validate: confirm fixed kernel active (uname, package changelog) and monitor logs for repeated OOPS for 7–14 days post‑rollout.
- Communicate: notify affected owners, record CVE references and kernel commit IDs in change tickets, and ensure rollback plans exist.
Closing analysis and conclusion
Microsoft’s public wording around CVE‑2025‑21885 is transparent and procedurally correct: it tells customers what Microsoft has validated so far and makes a promise to expand product mappings as inventory work continues. For Azure Linux customers, that is a clear, machine‑readable signal to act on. However, the important operational reality is that attestations are scoped to product inventories, not to every possible image or kernel build Microsoft or its partners might distribute. Because kernel composition is a build‑time artifact, other Microsoft‑distributed kernels or images could include the same bnxt_re code depending on configuration and backports. Administrators must therefore treat the MSRC statement as authoritative for Azure Linux — and as a prompt to perform host‑level verification across their own estate for other Microsoft artifacts.Action summary (one line): If you run Azure Linux images, apply Microsoft’s Azure Linux kernel update; if you run other Microsoft‑supplied Linux artifacts (WSL, Marketplace images, custom appliances), verify bnxt_re presence and the kernel build before assuming they are unaffected — and track Microsoft’s VEX/CSAF updates for any expansion of the product mapping.
End of report.
Source: MSRC Security Update Guide - Microsoft Security Response Center
