CVE-2025-38735: Azure Linux Patch Guide and Attestation Limits

Microsoft’s short MSRC attestation — “Azure Linux includes this open‑source library and is therefore potentially affected” — is accurate for the product it names, but it is not a categorical guarantee that no other Microsoft product could ship the same vulnerable Linux kernel component; Azure Linux is simply the only Microsoft product Microsoft has publicly mapped for CVE‑2025‑38735 so far. rview
CVE‑2025‑38735 is a medium‑severity Linux kernel vulnerability in the Google Virtual Ethernet (gve) driver. The defect allows an ethtool ioctl to dereference freed or NULL pointers if an ethtool operation is dispatched after the driver's shutdown() path has executed, which can produce a kernel panic and cause a denial‑of‑service (system crash). Upstream maintainers fixed the problem by marking the netdevice as detached during shutdown so the ethtool handler will not forward operations to the driver after teardown. (suse.com)
This issue has two practical characteristics that matter to system operators:

• The attack vector is local: a user or process able to issue an ethtool ioctl (or trigger a helper that invokes ethtool) while the kernel is running shutdown() can cause a panic. The vulnerability surface is not a remote network‑facing ioctl; it is triggered by local control over ethtool operations.
• The timing window is unusual: the problem shows up when shutdown() has torn down internal gve structures but the kernel has not yet fully quiesced userspace. That implies forced or accelerated reboots (for example hypervisor‑driven forced resets or cloud provider VM forced reboots) are the most plausible real‑world triggers. Upstream has documented GCP observations where this timing could be hit. (suse.com)

Because this is a driver‑level crash path, the outcome is denial of service (host kernel panic). There is no public evidence that the bug leads to memory disclosure or privilege escalation; the fix is defensive (prevent ethtool dispatch) rather than a redesign of the driver's trust boundaries.

---

What Microsoft said — and what that wording means​

Microsoft’s public advisory language that names Azure Linux and states it “includes this open‑source library and is therefore potentially affected” is an authoritative product‑scope attestation — it tells customers Microsoft has inspected the Azure Linux artifacts and found the upstream component in the builds Microsoft ships. That statement is useful and actionable fers because it defines an immediate risk and a remediation path for that product family.
However, that wording must be read narrowly:

• It does not assert exclusivity. Saying “Azure Linux includes X” is different from saying “no other Microsoft product includes X.” Microsoft has explicitly committed to expanding its machine‑readable CSAF/VEX attestations and to update CVE mappings if additional Microsoft products are later found to carry the same upstream code; this is an operational promise to extend inventory mappings, not a technical statement proving absence. Treat the Azure Linux attestation as a positive confirmation for that product, and treat the lack of attestatoft artifacts as an absence of attestation, not proof of absence.
• Many modern vendors publish product‑level VEX/CSAF mappings incrementally. Microsoft started publishing machine‑readable VEX/CSAF outputs in the October 2025 timeframe and has used the same phrasing across multiple kernel advisories — naming Azure Linux where inventory checks have been done, and promising to update records when other Microsoft products are validated. That process means product coverage in MSRC entries is evolving; it is normal for initial entries to map a single product and for the mapping to expand later.

In short: Microsoft’s wording is standard and truthful — Azure Linux is confirmed as a carrier — but it does not prove other Microsoft artifacts are unaffected. You must validate other Microsoft kernels and images yourself (or wait for Microsoft to publish a VEX/CSAF update that adds them).

---

Upstream technical detail and the fix​

The upstream change is small, well‑targeted, and available in the stable kernel trees. The key fix is to call netif_device_detach() from gve_shutdown(), which marks the netdevice as detached and prevents the ethtool ioctl handler from dispatching operations to the driver after shutdown(). The patch landed in upstream stable branches and was pushed into multiple stable trees. The patch summary and the commit are publicly visible in the stable patch series.
Why this matters technically

• shutdown() in many drivers is designed to stop DMA and hardware activity quickly; as a consequence it sometimes performs lightweight teardown without fully unregistering devices. This leaves a short interval where a netdev may still be visible to userspace (and helpers like ethtool) while internal driver pointers have already been freed. A protective call to netif_device_detach() tells the kernel core and helpers that the device should no longer be considered operational and prevents ioctl dispatch into the driver code during this fragile window.
• The fix follows an established defensive pattern: mark the device detached early, then proceed with teardown. This is a minimal, correct mitigation that avoids broad behavioral changes or performance regressions.

Which kernel releases carry the fix?

• The upstream commit ID and its inclusion in stable trees are tracked in kernel patch indexes; kernel maintainers have merged the fix into recent stable release branches. Downstream distributions (Debian, Ubuntu, SUSE, and vendors such as Wind River) list the advisory in their security trackers and publish fixed package versions. Check your distribution vendor’s advisory for the exact fixed package version number. (suse.com)

---

Who else ships the gve driver?​

The important practical question for Microsoft customers is: beyond Azure Linux, does any other Microsoft product ship the gve driver and therefore potentially carry CVE‑2025‑38735?
Short answer: Azure Linux is the only Microsoft product Microsoft has publicly attested to include the gve component for CVE‑2025‑38735 so far. That is a public, product‑level inventory statement. But that statement does not prove exclusivity — other Microsoft artifacts may or may not include the driver depending on build choices, kernel versions, and platform configuration.
Why you should not assume exclusivity

• Kernel driver presence is an artifact‑specific property. A single vendor (Microsoft) builds multiple kernel artifacts for different products: the Azure Linux kernels and images, CBL‑Mariner/CBL‑Mariner‑derived kernels, WSL2 kernels, specialized Azure hypervisor/VM kernels used in some products, and images embedded into appliances or device firmware. Each of those artifacts can be built with different kernel versions, compile‑time configuration, and modular selections. Whether gve is present depends entirely on the kernel configuration and the set of drivers enabled in that specific build; there is no global "Microsoft kernel feature list" that applies uniformly across every product.
• Microsoft’s VEX/CSAF program is incremental. Microsoft has said it will expand the product mapping as its inventories progress. If you rely on MSRC attestations alone, you will see an initial mapping (Azure Linux here) and subsequent updates if the company discovers the same upstream source in other Microsoft products. Until those attestations appear, operators must either (a) perform artifact‑level checks themselves, or (b) treat Microsoft images as unverified for that CVE.

Plausible Microsoft artifacts that could, in principle, include gve

• Azure Linux kernels and Azure VM images — confirmed attestation by Microsoft for this CVE. This is the direct, published mapping; Azure Linux customers should update using Microsoft’s published fixed kernel packages or Azure image updates.
• CBL‑Mariner builds or other Microsoft Linux builds used internally or for cloud infrastructure — Microsoft builds multiple kernel variants for its distributions; earlier CVE mappings have sometimes included CBL‑Mariner kernels. Whether CBL‑Mariner kernels include gve depends on the kernel config and package contents for the specific release. Unless Microsoft’s CSAF/VEX lists CBL‑Mariner for this CVE, treat it as unverified and check local images.
• The WSL2 kernel shipped in Windows builds — Microsoft maintains a WSL2 kernel source and periodically publishes kernel updates in Windows Insider and stable Windows builds. Historically WSL2 kernels have been trimmed for userland compatibility and platform-specific features; they do not necessarily include every cloud‑provider driver. Whether the WSL2 kernel includes gve in a given Windows/WSL release depends on its kernel configuration and modules. Verify the running WSL2 kernel if you are concerned.
• Other Microsoft images or appliance kernels — for example specialized kernels used in Azure Marketplace appliances, managed images, or partner solutions. Each image must be checked.

Because of the above, the correct operator posture is: treat Azure Linux as confirmed and other Microsoft artifacts as unverified until proven otherwise.

---

How to verify whether a specific Microsoft kernel/image includes the gve driver​

If you are responsible for systems that run Microsoft‑branded artifacts (Azure Linux, WSL2 kernels, CBL‑Mariner images, Marketplace images), do the following artifact checks. These are simple, local commands you can run on a Linux host or in a WSL2 shell.

• Identify the running kernel and installed kernel packages:
• uname -a
• cat /proc/version
• Check for a built‑in gve driver symbol or module:
• Look for a module file:
• ls /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/google/gve*
• find /lib/modules/$(uname -r) -name 'gve'
• Check loaded modules:
• lsmod | grep gve
• If you have the kernel config, check whether the driver was enabled:
• zgrep CONFIG_GVE /proc/config.gz || grep CONFIG_GVE /boot/config-$(uname -r) || zgrep CONFIG_GVE /lib/modules/$(uname -r)/config*
• Search the kernel tree inside the distribution package:
• If you have a kernel source package or package that includes the kernel tree, search for:
• grep -R \"drivers/net/ethernet/google/gve\" /usr/src /usr/lib/modules
• Inspect image contents offline:
• For cloud images, unpack the image and check /lib/modules and /boot for the kernel and modules listed above.
• For WSL2, open the WSL2 shell and run the commands above against the running kernel.

If any of these checks find the gve module or drivers/net/ethernet/google/gve/gve_main.c inside the image/kernel, that artifact may be susceptible if it runs a kernel that predates the fix. The upstream references show the source file path and the commit that introduced the defensive netif_device_detach() call.

---

Practical remediation and mitigation steps​

If you confirm gve is present in a Microsoft artifact you manage, follow these prioritized steps:

• Patch to a fixed kernel package from your vendor immediately.
• For Azure Linux customers: install Microsoft’s patched Azure Linux kernel update or accept the updated Azure Marketplace image; Microsoft has published Azure Linux mappings and will publish fixes for that distro. Use the Azure update path for managed VM images.
• For other distributions or images that include gve:
• Apply the vendor’s kernel security update (Debian/Ubuntu, SUSE, Red Hat, Wind River, etc.). Distribution vendors have published CVE advisories describing the fix and fixed package versions. Examples include Ubuntu and SUSE advisories that list CVE‑2025‑38735 and fixed kernel packages.
• If you cannot immediately update:
• As a short‑term mitigation, avoid forcing shutdowns and scripted workflows that can trigger the shutdown() path while background processes can still call ethtool.
• Restrict local access to /sbin/ethtool or limit user privileges so unprivileged users cannot execute ethtool.
• Where possible, configure orchestration to gracefully quiesce userspace before rebooting VMs (this reduces the risk window where an ethtool operation races with shutdown()).
• Validate after patching:
• Reboot into the updated kernel and run the detection steps above to ensure the new kernel version includes the commit or that the gve module is updated.
• Confirm that vendor package versions match the fixed versions listed in the vendor advisories.
• Monitor vendor advisories and MSRC VEX/CSAF:
• Because Microsoft has committed to updating EUA/VEX attestations as inventory checks progress, watch MSRC advisories for follow‑on updates adding other Microsoft products or details. Do not assume absence of listing means absence of risk.

---

Risk assessment: real‑world exploitation likelihood​

• Attack potency: The bug leads to a kernel panic (availability impact). The CVSSv3 base score commonly assigned by distributions is 5.5/10 (Medium) reflecting a local, low‑privilege trigger and an availability result. It is not scored as remote code execution or confidentiality breach in current CVE entries. (suse.com)
• Exploitability in practice: Because the exploit path requires local ability to invoke ethtool and a narrow timing window during shutdown, the practical risk profile is moderate for multi‑tenant cloud VMs (forced reboots can be observed in cloud environments) and relatively low for single‑user desktops that follow graceful shutdown paths. Cloud customers running Azure or other provider images that include gve should prioritize patching because forced host operations or hypervisor callbacks make the timing window more plausible. (suse.com)
• Known active exploitation: As of current public advisories there is no widespread evidence of active exploitation beyond vendor reports of observed timing scenarios (for example forced forced‑reboot conditions on some cloud VMs). The immediate operational impact is service interruption risk, not data compromise. Vendors’ advisories emphasize updating kernels rather than applying workarounds.

---

Guidance for Microsoft customers (operational checklist)​

• If you run Azure Linux (confirmed carrier):
• Prioritize the Azure Linux kernel patch from Microsoft or apply the patched image. Microsoft’s attestation confirms Azure Linux contains the implicated code and therefore it is an immediate remediation priority.
• If you run other Microsoft artifacts (WSL2 kernels, CBL‑Mariner images, Marketplace images):
• Don’t assume they are unaffected. Perform the verification steps listed above (check for gve module, kernel config, module path).
• If you find gve present, treat the artifact as potentially vulnerable and apply vendor patches or update images.
• If you operate heterogeneous fleets:
• Use image scanning and automation to check for the presence of drivers and modules across images and kernels.
• Add a detection rule to your configuration management or EDR tools that searches /lib/modules and kernel configs for gve or the drivers/net/ethernet/google/gve path.
• For security teams:
• Track vendor advisories from Microsoft, Ubuntu, SUSE, and your distribution vendor; they publish fixed package versions and sometimes backported patches for long‑term support branches. (suse.com)

---

Strengths and limits of Microsoft’s attestation approach​

Strengths

• Microsoft’s product‑scoped attestation is transparent and actionable for customers who run Azure Linux — it tells them explicitly which Microsoft product to update and when Microsoft has validated the artifact. This reduces uncertainty for a large set of Azure customers and is consistent with modern VEX/CSAF practices.
• Publishing machine‑readable CSAF/VEX data (the October 2025 program start) is a material operational improvement; it enables automated customer tooling to ingest attestation mappings and speed remediation workflows. Microsoft’s commitment to update CVE mappings if they discover additional impacted products is good practice.

Limits / Risks

• Incremental coverage creates interim ambiguity. Until Microsoft completes inventory checks across all product lines, customers who use Microsoft‑branded kernels in other products must verify locally. The attestation alone does not absolve operators from doing artifact‑level checks.
• There is an operational risk if customers treat “not listed” as “not affected.” Absence of an attestation is not technical evidence of absence; it is simply the absence of a published mapping. Security teams should validate critical artifacts proactively rather than assuming they are out of scope.
• VEX/CSAF improves automation but only if coverage is broad and timely; the value of the program depends on consistent, complete inventory checks and prompt mapping updates.

---

Final verdict: Is Azure Linux the only Microsoft product potentially affected?​

• Publicly attested: Yes — Azure Linux is currently the only Microsoft product Microsoft has publicly attested to include the vulnerable upstream component for CVE‑2025‑38735. That attestation is authoritative for Azure Linux and requires immediate remediation action for Azure Linux customers.
• Technically exclusive? No — the attestation does not prove exclusivity. Other Microsoft artifacts (CBL‑Mariner kernels, WSL2 kernels, Azure Marketplace images, and any Microsoft‑built kernel artifacts) might include gve depending on build configuration and kernel version. The correct practitioner response is to verify artifacts under your control and to monitor Microsoft’s VEX/CSAF updates for expanded mappings.

---

Quick actionable checklist (concise)​

• If you run Azure Linux — update to Microsoft’s patched Azure Linux kernel immediately.
• If you run other Microsoft Linux artifacts — verify presence of gve (module, kernel config, drivers/net path); if present, patch or rebuild images with fixed kernels.
• If you cannot patch immediately — restrict local ethtool usage, avoid forced shutdowns, mitigate exposure for shared/cloud hosts.
• Add a scanning rule to your image pipeline to detect drivers/net/ethernet/google/gve in images.
• Monitor vendor advisories (Ubuntu, SUSE, Debian, Microsoft) for fixed package versions and update schedules.

---

CVE‑2025‑38735 is a specific, local‑trigger availability bug with a straightforward defensive fix upstream. Microsoft’s MSRC product attestation correctly identifies Azure Linux as a confirmed carrier for the vulnerable gve driver, and Microsoft will expand its machine‑readable attestation coverage if additional Microsoft products are found to ship the same upstream component. That makes Azure Linux the immediate, confirmed remediation priority — but it does not provide a blanket guarantee for any other Microsoft product. Validate artifacts, apply vendor kernel updates, and monitor MSRC/VEX updates to close the gap between attestation and full product coverage.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center