Short answer up front
No — Azure Linux is not the only Microsoft product that Microsoft has identified as including the affected ravb code. Microsoft’s CSAF/VEX entry for CVE‑2025‑21801 lists Azure Linux (Azure Linux 3.0) and CBL Mariner kernel builds as known/confirmed components that include the vulnerable ravb code path. Microsoft also makes clear it will update the advisory if it discovers impact in additional products. What you’re reading and why it matters
CVE‑2025‑21801 is a Linux‑kernel vulnerability that was fixed upstream in early 2025. The bug is inside the ravb (Renesas Ethernet AVB) network driver and is caused by missing use of the rtnl (routing/netlink) lock in the suspend/resume path; in short, some ravb open/close and Wake‑on‑LAN operations could run without the required rtnl protection, which produces RCU/lockdep warnings and can cause kernel instability on affected platforms. That upstream description and the developer patches are public and tracked in the usual CVE/NVD feeds. Why the question about “only Azure Linux?” is understandable
Microsoft’s MSRC entry and accompanying VEX/CSAF JSON make it clear why customers asked whether Azure Linux was the only Microsoft product affected: the MSRC product_tree names Azure Linux (and specific kernel package versions) and CBL Mariner kernel builds explicitly as the Microsoft components that contain the vulnerable kernel(s). Because Microsoft publishes product‑component mappings via CSAF/VEX, a customer seeing Azure Linux called out may reasonably ask whether other Microsoft offerings (WSL, Windows, Azure services, device OSes, etc. are affected. Microsoft’s VEX explicitly states the products it has identified and commits to updating that information if other products are found to be impacted. Technical background — what ravb is and where it normally appears
A few technical facts make the practical risk model easier to understand:
- ravb is a Renesas-specific Ethernet driver (Renesas “Ethernet AVB” support) — it lives under drivers/net/ethernet/renesas in the kernel sources and is intended for Renesas SoCs (for example R‑Car families, GbEth IP in RZ/G series and related Renesas platforms). It is not a generic x86 NIC driver.
- The kernel Kconfig for RAVB shows that the driver is conditioned on Renesas targets (it depends on ARCH_RENESAS or related build options). That means a kernel built for generic x86_64 or mainstream Arm server hardware normally won’t enable or include ravb unless explicitly configured to do so.
- In practice, ravb shows up in kernels used on Renesas evaluation boards, embedded appliances, industrial systems, and SoC‑based devices (and in Linux builds where Renesas support was selected). Upstream patches, tests, and kernel logs that triggered the CVE all point at Renesas test hardware or Renesas target kernels.
Put another way: ravb is target‑hardware specific. If your Microsoft product or image runs a kernel that was built for general‑purpose x86/Arm server hardware and does not include Renesas platform support, that kernel normally will not include ravb. This is why many mainstream Microsoft assets (e.g., Windows itself, Windows drivers, and most x86 cloud VM images that use kernels built without Renesas support) are unlikely to contain the ravb driver.
What Microsoft’s VEX/CSAF entry actually says (and why it matters)
Microsoft’s published VEX JSON for CVE‑2025‑21801 lists the specific Microsoft components that Microsoft has analyzed and how they classified their status:
- The VEX lists Azure Linux 3.0 kernel packages (several azl3 kernel package versions) and CBL Mariner 2.0 kernel (a cbl2 kernel package version) as known_affected in Microsoft’s product_tree for this CVE. That is an explicit statement that those particular Microsoft kernel builds include the relevant kernel code in versions examined by Microsoft.
- The VEX also records Microsoft’s commitment to update the advisory if additional Microsoft products are found to be affected. In other words, the list is Microsoft’s current authoritative inventory for their products as of the document release and is subject to change if other products contain affected kernels.
How to interpret “affected” in practice (risk model)
- Inclusion ≠ exploitability everywhere: The upstream fix (the ravb patch) addresses a synchronization problem that typically triggers in suspend/resume and in sequences of network device operations on hardware that exercises Renesas NIC functionality. Even when the source and module exist inside a kernel build, exploitability depends on hardware, configuration, and runtime behavior. That said, the correct engineering response is to treat an affected kernel component as vulnerable until a vendor provides a fix or an authoritative mitigation.
- Where you’ll most likely see this: devices and kernels that are built with Renesas support enabled. Those are most commonly embedded and SoC platforms (e.g., evaluation boards, industrial devices), not generic x86 or Arm server images. Still, Microsoft’s own kernel packages can include many architectures/configurations — which is why Microsoft’s engineering team mapped the exact kernel packages they ship.
How to check whether your systems / Microsoft images are affected
If you operate Microsoft‑distributed Linux images, or if you run Linux kernels from Microsoft (Azure Linux, CBL Mariner, WSL custom kernels, etc., here are quick, practical checks to perform on any system:
1) Check the kernel config for CONFIG_RAVB
- On a running Linux system: zcat /proc/config.gz | grep CONFIG_RAVB (or check /boot/config-$(uname -r). If CONFIG_RAVB=y or =m, the ravb driver was built in or as a module. If CONFIG_RAVB is not present (or is =n), the kernel build doesn’t include it. (This is the most direct test; ravb depends on Renesas target selections in kernel build.
2) Look for the module or driver on disk / at runtime
- Check lsmod | grep ravb (running system) or ls /lib/modules/$(uname -r) | grep -i ravb to see if a module is installed. Also grep for drivers/net/ethernet/renesas paths in your installed kernel sources or module list. If there is no ravb module and the kernel config shows it off, you’re not affected at the kernel/module level.
3) For Microsoft image consumers (Azure, Windows Subsystem for Linux):
- For Azure VM images: check the kernel package version and mapping in Microsoft’s VEX/CSAF (MSRC) entry to see if your image’s kernel package is listed among known_affected versions; then verify the running kernel config as above. Microsoft’s VEX includes the specific kernel package identifiers that they analyzed.
- For WSL: Microsoft builds WSL kernels from their WSL2‑Linux‑Kernel repo and publishes a WSL kernel config (Microsoft/config‑wsl). Unless the WSL build was explicitly configured to include Renesas/arch‑Renesas support, the WSL kernels typically do not include Renesas SoC drivers by default, so ravb would typically not be present on standard WSL kernels. If you or an administrator uses a custom WSL kernel, inspect that custom kernel’s config for CONFIG_RAVB. (Microsoft’s WSL kernel repo and build instructions are public.
Recommended actions and mitigations
If you are responsible for systems or images that might be affected, take these practical steps:
- Inventory first: use the checks above (kernel config, /lib/modules, lsmod, package/kernel version) to find all systems that contain or load the ravb module. For Azure customers, check the exact Azure Linux / kernel package versions in your subscriptions against Microsoft’s VEX entry.
- Patch: Where Microsoft has published updated kernel packages that include the upstream ravb fix, apply the vendor packages. Microsoft’s VEX shows which kernel package versions the Microsoft team has identified; use those entries as a baseline and watch MSRC for updated remedial releases. If a vendor patch is not yet available for an affected product, watch for updates or use the temporary mitigations below.
- Temporary mitigations (if you cannot immediately patch):
- If the ravb driver is built as a loadable module, blacklist the module (e.g., add a blacklist entry for ravb) and rebuild initramfs where required — but only do this when you know the module is not required for any legitimate hardware on that machine (this is a host‑dependent action, and for VMs in cloud images it is often safe because cloud hosts rarely use Renesas SoCs).
- If the driver is built‑in (CONFIG_RAVB=y), you cannot unload it at runtime; in that case the only true mitigation is to move to a patched kernel build.
- Review device scope: If you manage IoT/embedded fleets or device images that use Renesas hardware, prioritize patching those images and factory firmware/toolchains quickly — those devices are the most realistic exploitation surface for ravb issues.
- Subscribe to vendor feeds: Because Microsoft explicitly states it will update its CSAF/VEX entries if it finds additional impacted products, subscribe to MSRC notifications and the VEX JSON feed for CVE‑2025‑21801 so you receive authoritative product and remediation updates from Microsoft.
Why mainstream Microsoft offerings are unlikely to be affected (but still check)
- Windows (non‑WSL) is not a Linux kernel distribution and does not include the Linux ravb driver; therefore Windows desktop/server builds are not within the Linux ravb vulnerability scope.
- WSL uses a Microsoft‑built Linux kernel; while WSL now supports ARM64 kernels and custom kernels, Microsoft’s WSL kernels are aimed at generic x86_64 and Arm host machines and normally do not enable Renesas/ARCH_RENESAS options unless someone explicitly builds a custom kernel with those settings. So default WSL installs are unlikely to have ravb enabled; nonetheless, any custom kernel should be checked.
- Azure public VM instances and images: Microsoft’s VEX lists the exact Azure Linux kernel packages the company has examined and marked as known_affected (and CBL Mariner). If you run different Azure VM images or custom images, verify the kernel config in your images rather than assuming they’re identical to the VEX entries.
A short checklist for administrators (actionable)
- Inventory: run zcat /proc/config.gz | grep -i RAVB or check /boot/config-$(uname -r) on each Linux host. If CONFIG_RAVB is present, treat as potentially affected.
- Module check: lsmod | grep ravb and ls /lib/modules/$(uname -r)/ravb.
- Consult Microsoft VEX: confirm whether your specific Azure Linux / CBL Mariner kernel package is in Microsoft’s known_affected list.
- Patch when available: apply vendor/kernel updates that include the upstream fix; for Microsoft images, follow MSRC guidance for Azure Linux/CBL Mariner updates.
- If you cannot patch immediately: for module builds, consider blacklisting ravb where safe; for built‑in builds, plan emergency kernel rebuild/replace.
Where I looked and sources you can follow to verify
- Microsoft’s CSAF / VEX for CVE‑2025‑21801 (the official Microsoft machine‑readable advisory listing affected Microsoft products and kernel package identifiers). This is Microsoft’s authoritative product mapping for the CVE as of the document’s latest revision.
- NVD / CVE listings and aggregator pages (NVD, CVE Details, Oracle Linux CVE page) that summarize the vulnerability and point to the upstream kernel commit that fixes the problem. Use these to cross‑check severity and upstream patch references.
- Upstream Linux kernel tree, Kconfig and the source directory drivers/net/ethernet/renesas where ravb lives — these documents show the RAVB driver and its build dependencies, and they explain why the driver only appears in Renesas‑targeted kernels (CONFIG_RAVB depends on Renesas/arch selections). That upstream context is important for deciding where to prioritize fixes.
Bottom line (practical summary)
- Microsoft has identified Azure Linux (specific azl3 kernel packages) and CBL Mariner (a cbl2 kernel package) as components that contain the vulnerable ravb code path; they will update that inventory if they find additional products. If you run Azure Linux or those CBL Mariner kernel packages, you must treat the kernels as potentially affected and follow Microsoft’s remediation guidance.
- If you operate most mainstream x86_64 cloud VMs, WSL default kernels, or Windows hosts, you are unlikely to have ravb present because ravb is Renesas SoC specific. Nevertheless, always confirm by checking the running kernel config and the module list — don’t rely on assumptions.
If you want, I can
- Produce a short script you can run across a fleet to detect presence of CONFIG_RAVB and the ravb module, or
- Build a one‑page remediation runbook you can hand to your cloud or device teams (includes commands, timeline, and vendor contact pointers), or
- Monitor the MSRC feed and send you a concise alert summary if Microsoft updates the VEX (e.g., if they find additional affected products).
References (select authoritative items cited above)
- Microsoft Security Response Center — CSAF/VEX JSON for CVE‑2025‑21801 (product mapping, current_release_date, known_affected list).
- NVD (National Vulnerability Database) — CVE‑2025‑21801 description and references.
- Linux kernel source / Kconfig (drivers/net/ethernet/renesas, RAVB config) — shows ravb driver location and Renesas build dependency.
- CVE aggregators and trackers (examples: cvepremium / cve details) that reproduce the CVE summary and link to upstream patches.
— End of article —
Source: MSRC
Security Update Guide - Microsoft Security Response Center