CVE-2025-37909 Lan743x memory leak: Azure Linux attestation and patch guidance

The Linux kernel vulnerability tracked as CVE‑2025‑37909 is a targeted memory‑leak fix in the Microchip LAN743x Ethernet driver (lan743x) that matters chiefly because Microsoft’s MSRC advisory explicitly attests that Azure Linux includes the implicated upstream code, while leaving open whether other Microsoft‑distributed kernel artifacts might also ship the same vulnerable driver. ([lists.openwall.netall.net/linux-cve-announce/2025/05/20/13)

Background / Overview​

CVE‑2025‑37909 was assigned for a defect in the lan743x driver that can leave socket buffers (skbs) mapped in a way that prevents proper freeing when Generic Segmentation Offload (GSO) is enabled. The kernel‑level patch changes how the driver maps skbs — the fix forces the skb to be mapped to the LS descriptor instead of the EXT descriptor in the zero‑fragment GSO case, which allows the skb to be freed normally and closes the leak. The upstream disclosure and kernel CVE announcement provide the technical narrative and the exact commits that introduced and fixed the regression.
What this means practically: on systems running a kernel that includes the affected lan743x driver and that also enables GSO, sustained traffic patterns that trigger the buggy path can progressively consume kernel memory. Over time this can degrade performance, trigger OOM behavior, or impact availability. The vulnerability is a resource‑exhaustion/availability issue rather than a remote code‑execution or data‑exfiltration vector. Multiple downstream trackers rate the impact as availability‑oriented and give medium–low CVSS profiles depending on distribution and packaging.

---

The MSRC wording: product attestation, not a universal exclusion​

Microsoft’s public advisory language for this and similar Linux kernel CVEs has followed a consistent pattern: the MSRC entry states that Azure Linux includes the implicated open‑source library and is therefore potentially affected, and then explains that Microsoft has begun publishing machine‑readable CSAF/VEX attestations to clarify which Microsoft products are in scope. That is an explicit attestation that Azure Linux (Microsoft’s cloud‑focused Linux distribution family) contains the upstream component Microsoft inspected, and therefore Azure Linux customers should treat it as in‑scope for remediation. Microsoft further commits to update the CVE mapping if additional Microsoft products are later discovered to ship the vulnerable code.
This wording is precise by design: it is a product‑level inventory statement for Azure Linux. It is not equivalent to saying “no other Microsoft product contains the code.”osoft is telling customers what it has verified so far and promising to expand the attestations as more build inventories are completed. Treat the attestation as authoritative for Azure Linux, and treat the absence of attestations for other Microsoft artifacts as absence of attestation, not proof of absence.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the lan743x driver for CVE‑2025‑37909 at the time of that advisory, but any Microsoft artifact that ships a Linux kernel build containing the lan743x driver and a kernel configuration that enables the relevant path (and runs with GSO enabled at runtime) could be a carrier. That includes, but is not limited to:

• Windows Subsystem for Linux (WSL2) kernel builds that Microsoft distributes. Microsoft publishes the WSL2 kernel source and maintains distinct kernel images for WSL; those kernels can and do include many upstream drivers and are independently versioned. If a WSL2 kernel build uses a kernel commit range predating the fix and includes CONFIG_LAN743X, it could contain the same code.
• Azure‑tuned kernels (commonly packaged or labelled as linux‑azure or similar) that Canonical and other distributors maintain for Azure VM images. Those kernels are distinct artifacts and Marketplace images and may be built with different configuration options.
• Azure Marketplace images, AKS node images, or any Microsoft‑published VM/appliance image that bundles a Linux kernel. Whether each image is affected depends on the kernel version and the build configuration that produced it.
• Other Microsoft‑distributed or partner images that embed Linux kernels (for example: partners’ Marketplace offerings, specialized appliances, and some container host images), again depending on which kernel commit and config they shipped.

Multiple independent analyses and expert commentary make the same operational point: Microsoft’s attestation is product‑scoped and time‑boxed; until Microsoft publishes additional attestations—or until you inspect the specific artifact—other Microsoft artifacts must be treated as possible carriers, not presumed clean.

---

Why the distinction matters (technical reasons)​

The presence of a particular upstream file or bug in a shipped kernel binary is an artifact property, not a universal vendor property. Kernel source control, version choice, backports, and build‑time configuration determine whether a given distribution or image includes a given driver and whether that driver contains the vulnerable code.

• Kernel version and commit range: The bug in lan743x is present in upstream kernels introduced around commit 23f0703c (4.17 era) and was fixed in the stable kernel series (fixes appear in 5.15.182 and several stable backports). A kernel built from a tree that predates the fix will include the bug unless the packager cherry‑picked the upstream fix. The upstream linux‑cve announcement lists the exact commits.
• Kernel configuration flags: lan743x is controlled by CONFIG_LAN743X (a driver built as a module or built‑in), so a kernel that never enabled the driver will not carry the vulnerability. The LKDDb entry for CONFIG_LAN743X documents the module and where it lives in the source tree (drivers/net/ethernet/microchip).
• Distribution backports and patch policies: Many vendors backport security fixes into older stable kernel packages rather than shipping a higher kernel version, so distribution packages might be patched even when their version number is older. Conversely, images that ship kernels from OS vendors or Microsoft’s own build pipeline might not yet have the backport. Always verify by mapping the kernel to upstream commit IDs or package changelogs.

---

How to verifyft‑distributed systems are affected (operational checklist)​

Below is a prioritized checklist you can use immediately. These steps assume you have access to the target systems and can run standard Linux commands.

• Inventory and prioritize Azure Linux instances
• If you run Azure Linux images, treat them as confirmed in‑scope per Microsoft’s attestation. Patch these hosts first following Microsoft’s guidance and schedule a reboot. Microsoft’s CSAF/VEX attestation makes Azure Linux the canonical starting point.
• Identify other Microsoft kernel artifacts in your estate
• WSL2: check the WSL kernel release used on endpoints. From a WSL shell run: uname -r and compare with Microsoft’s published WSL kernel releases. The WSL2 kernel sources and release guidance are public.
• Azure VM images and AKS node pools: determine whether images are using vendor kernels or linux‑azure kernels. Look at the kernel package names (e.g., linux‑azure) and the kernel package changelogs. Canonical publishes linux‑azure package details.
• Quick on‑host checks (run as root or with sudo)
• Check kernel release: uname -a
• Check kernel config for lan743x:
• If /proc/config.gz exists: sudo zgrep -i LAN743X /proc/config.gz
• Or check /boot/config-$(uname -r): grep -i LAN743X /boot/config-$(uname -r)
• Inspect modules directory:
• ls /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/microchip | grep -i lan743x
• Check loaded modules:
• lsmod | grep -i lan743x
• Modinfo (if module present):
• sudo modinfo lan743x
• If you cannot find kernel config, check for module symbols inside the kernel modules tree for the running kernel.
• Map kernel version to upstream commits
• Use the distro/kernel package changelog and upstream linux‑cve announcement to determine whether the kernel includes the fix. The linux‑cve announcement and LKML posts list the commit IDs that fixed the bug and the stable kernel release that contained the patch; map those commits to your vendor’s changelog. Do not assume that a kernel version number alone proves presence/absence — check the changelog or git commit mapping.
• If you identify a suspect kernel image but cannot immediately patch:
• Consider temporary mitigations (see below).
• Schedule patching windows and reboots for impacted hosts.

---

Detection and verification — concrete commands and what they tell you​

Use these practical commands as a starting point. Run them on each host you need to assess.

• Kernel release:
• uname -r
• Check kernel config for the build:
• sudo zgrep -i LAN743X /proc/config.gz
• sudo grep -i LAN743X /boot/config-$(uname -r)
• If output shows CONFIG_LAN743X=m or =y, the driver was enabled in that kernel.
• Find the driver module:
• ls /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/microchip | grep -i lan743x
• sudo modinfo lan743x (if present)
• If module not installed but you have the kernel source tree or package metadata, look for drivers/net/ethernet/microchip/lan743x_main.c in the source and confirm whether it contains the patched change. The upstream kernel commits that fix the issue are referenced in the linux‑cve announce.

Important operational note: a kernel package may be patched without its version number changing to a higher upstream major release (backports). Always rely on vendor package changelogs or the presence of the specific commit ID in the package build to declare “fixed.”

---

Immediate mitigations you can apply now​

If you identify hosts that carry the vulnerable kernel and you cannot apply the vendor/packaged fix quickly, you can take short‑term mitigations to reduce exposure:

• Disable GSO on affected interfaces (temporary, performance‑impacting):
• sudo ethtool -K <ifname> gso off
• Note: disabling GSO (or disabling other offloads such as GRO/LRO) reduces CPU/networking performance — test and document the impact before wide deployment.
• Reduce network load or redistribute traffic to avoid sustained conditions that exercise the driver’s buggy path.
• If the driver is built as a module aached hardware matching the PCI IDs), consider blacklisting the module (with caution) until you can patch. Blacklisting can break hardware functionality; evaluate on a per‑system basis.

These are stopgap measures. The recommended fix remains: update to a kernel that includes the upstream patch or apply your vendor’s backported package that includes the lan743x fix. The upstream linux‑cve announce and distribution advisories identify the fixed commits and recommended upgrade paths.

---

Remediation: patch, test, and automate​

• Patch priority
• High priority for Azure Linux hosts (Microsoft attested product). Apply vendor‑provided kernel updates as published and reboot hosts to activate the new kernel. Microsoft has made Azure Linux an explicit remediation priority via its CSAF/VEX attestation.
• Next prioritize systems in your environment that run Microsoft‑distributed kernels (WSL2 endpoints, linux‑azure VMs, Marketplace images), followed by third‑party images that you operate.
• Test
• Take a representative set of systems for testing. Confirm that the new kernel or package resolves the issue and that GSO and other networking offloads operate correctly under realistic load.
• Automate detection using vendor attestations
• Integrate Microsoft’s CSAF/VEX feeds (and distro advisories) into your vulnerability management automation so that when Microsoft updates a CVE’s product mappings you receive an automatic signal. Microsoft began publishing machine‑readable CSAF/VEX attestations to improve mapping transparency; incorporate those feeds into your triage pipeline.
• Long‑term: inventory and artifact provenance
• Build or extend a kernel‑artifact inventory that maps every image, appliance, and WSL kernel in your estate to a kernel release, package name, and build metadata (ideally commit IDs). That allows quick deterministic mapping from CVE commit IDs to impacted artifacts rather than relying on manual heuristics. Many vendors (including Microsoft) are publishing VEX/CSAF attestations precisely to make this mapping automatable.

---

Risk assessment and likely impact​

• Technical severity: the bug is a memory‑leak/local availability bug. Trackers and distro advisories list CVSS vectors with availability impact and a local attack vector; distribution scores vary from low/medium depending on packaging and audience. The core consequence is gradual memory consumption leading to degraded networking and service availability under load.
• Exploitability: exploitation requires local or near‑local conditions that exercise the driver path (network traffic patterns with GSO enabled and the specific fragmenting behavior). This is not a remote code execution CVE — the practical risk is DoS via resource exhaustion rather than arbitrary code execution.
• Scale: the risk is concentrated on systems that actually run Microchip LAN743x hardware or where the driver is present in the kernel image and GSO is enabled. For cloud images without the hardware, presence of the driver in the kernel binary matters only if the virtualized environment exposes the device or module is loaded; for WSL and VM images the driver presence is an artifact property of the kernel build.

---

Why you should not assume “only Azure Linux” means “only Azure Linux will be hit”​

A succinct operational takeaway: Microsoft’s attestation that Azure Linux includes the implicated code is authoritative and actionable for Azure Linux customers. However, Microsoft’s statement is not a technical guarantee that other Microsoft‑published kernels and images are free of the code; it is a status update on what Microsoft has completed inventorying so far. Until Microsoft publishes additional VEX/CSAF attestations or until you verify artifacts locally, treat other Microsoft kernel artifacts (WSL2, linux‑azure kernels, Marketplace images, AKS nodes, etc.) as candidates for assessment. Security teams should assume potential exposure and verify.

---

What we checked to reach these conclusions​

• Upstream linux‑cve announcement and LKML patch messages describing the bug, the fix, and the commit IDs. These confirm the exact source file (drivers/net/ethernet/microchip/lan743x_main.c) and the stable kernel release that included the fix.
• NVD, Debian, Ubuntu, and other distro trackers for packaging status and CVSS/impact notes for CVE‑2025‑37909. These independent trackers show the vulnerability description and how distributions are treating the fix.
• LKDDb and kernel configuration references documenting CONFIG_LAN743X and the driver location in the kernel source tree. This validates how to detect the driver in kernels.
• Microsoft’s public transparency blog on CSAF/VEX and multiple Microsoft advisory entries that use the same attestation language; independent forum analyses highlight the operational meaning of those attestations (product‑scoped, not exhaustive).
• Microsoft’s published WSL2 kernel sources and documentation showing Microsoft maintains and distributes distinct Linux kernel artifacts that can carry upstream drivers. This underpins the point that WSL builds could be carriers.

If you need hands‑on help mapping commit IDs to packages, or want an automation script to scan a fleet’s images for CONFIG_LAN743X and kernel commit mapping, that can be produced and tested against a representative sample set.

---

Final recommendations (prioritized)​

• Patch all Azure Linux hosts immediately with Microsoft’s published kernel updates and reboot to apply the fix. Treat Azure Linux as confirmed in‑scope per MSRC’s attestation.
• Inventory other Microsoft kernel artifacts in your environment (WSL2 endpoints, linux‑azure VMs, Marketplace/AKS images). Use the commands and mapping guidance above to determine if those artifacts include CONFIG_LAN743X or the pre‑fix commit range.
• If you cannot patch quickly, apply temporary mitigations (disable GSO on affected NICs, reduce traffic patterns that trigger the defect, or blacklist the module where safe) with an operational caveat about performance impact.
• Integrate vendor CSAF/VEX feeds and vendor advisories into your triage automation so you get immediate notice when Microsoft expands VEX/CSAF attestations to additional products.
• Maintain an artifact provenance inventory that maps images and kernels to upstream commit IDs. This enables deterministic mapping for future kernel CVEs and reduces reliance on ad‑hoc assumptions.

---

CVE‑2025‑37909 is a narrowly scoped kernel driver memory leak that is straightforward to fix via vendor kernel updates. Microsoft’s public statement that Azure Linux includes the implicated open‑source library is a useful, actionable attestation for Azure Linux customers — but it is not a blanket guarantee that all Microsoft artifacts are free from the code. Operators should treat the attested Azure Linux mapping as authoritative and proceed to patch immediately, while also performing artifact‑level verification across WSL kernels, linux‑azure images, and any Microsoft‑distributed images in their estate. Keep your automation tuned to Microsoft’s CSAF/VEX updates and map kernel commit IDs to package changelogs for a fast and reliable remediation posture.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center