Microsoft’s public advisory for CVE-2025-38422 confirms that Azure Linux images include the upstream Linux kernel code that required a fix in the lan743x Ethernet driver, but that product-level attestation is
not an automatic guarantee that no other Microsoft-distributed artifacts contain the same driver — it only confirms what Microsoft has inventory-checked so far.
Background / Overview
CVE-2025-38422 is a Linux-kernel vulnerability recorded against the net/lan743x driver. The upstream fix adjusts the reported
EEPROM and
OTP sizes for the PCI1xxxx “hearthstone” family of LAN743x devices (maximum OTP =
8 KB, maximum EEPROM =
64 KB), and closes an out‑of‑bounds read/write vector by returning the correct EEPROM length based on the specific device. The issue was merged into the kernel stable trees and has been reflected in downstream distribution advisories. Technically this is a driver correctness bug that prevents out-of-bounds accesses when software probes or manipulates device EEPROM/OTP regions. The vulnerability is local to kernel/device interaction (not a simple unauthenticated remote RCE) and, depending on context and access, can cause kernel stability issues or enable privilege-escalation paths when combined with other kernel memory corruptions. Distribution trackers list this as an important/medium-importance fix and mapped vendor package releases provide the practical remediation path.
What Microsoft actually said — the wording and why it matters
Microsoft’s MSRC advisory language for this class of Linux-kernel CVEs follows a consistent structure: the company publishes a machine-readable CSAF/VEX attestation for the product artifacts it has inventory-checked, starting with the Azure Linux distribution family. For CVE-2025-38422 the MSRC FAQ explicitly states that
“Azure Linux includes this open-source library and is therefore potentially affected” and adds that Microsoft began publishing CSAF/VEX attestations in October 2025 and will update the CVE entry if additional Microsoft products are identified to ship the same upstream component. That phrasing is authoritative for Azure Linux but deliberately scoped. Two operational realities follow from this wording:
- Microsoft’s statement is a product-level inventory attestation — it affirms that Microsoft has inspected Azure Linux artifacts and found the vulnerable upstream component in those builds. For customers running Azure Linux images, that attestation is the canonical signal for exposure.
- The statement is not the same as a corporate-wide exclusion. Absence of an attestation for another Microsoft product is absence of attestation, not proof of absence of the vulnerable code. Other Microsoft-distributed artifacts can still carry the same upstream kernel code depending on kernel version, configuration and packaging.
Put simply: Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include this particular upstream kernel component for CVE-2025-38422. It is not — and should not be read as — definitive evidence that other Microsoft products cannot contain the same code.
Why the nuance matters to defenders and administrators
Modern vendors ship many distinct Linux-based artifacts: distribution images, cloud VM images, curated Marketplace appliances, container base images, managed-node images (AKS), and platform-specific kernels used by services or developer tooling (for example WSL2). Each of those artifacts can be built from different kernel trees, include different backports, and use different build-time CONFIG_
flags. As a result, whether the lan743x driver (or any other driver) is present in a given artifact is an artifact-level* property, not a product-level guarantee.
- A kernel source tree can contain net/drivers/net/ethernet/lan743x code, but that code will only be present in a shipped kernel image if the kernel version, applied backports, and build configuration include it.
- Distributions and cloud vendors often take kernel stable commits and backport fixes; whether a given vendor image is fixed is determined by the vendor’s published kernel package and changelog.
Because Microsoft has committed to publishing VEX/CSAF attestations product-by-product, the initial attestation for Azure Linux is a transparency improvement — but it leaves operators responsible for verifying other Microsoft-supplied artifacts they run.
Independent verification: what multiple sources show
Cross-checking independent vulnerability trackers and vendor advisories confirms the technical facts of the fix and shows how distributions mapped the change:
- The NVD entry records the CVE summary and links the upstream fix description (adjusting OTP/EEPROM max sizes and preventing out-of-bounds accesses). The NVD record is currently informational for this CVE.
- Distribution and cloud advisories list affected/fixed kernel package versions. For example, Amazon’s ALAS and Ubuntu trackers recorded the issue and mapped fixed kernel images that resolve the lan743x EEPROM/OTP bounds handling. Those advisories are the operational route for most cloud and on-prem admins to remediate vulnerable kernels.
- Aggregated CVE portals that index kernel-stable commits reference the upstream commits that change max EEPROM/OTP size constants and that return the correct length for specific PCI1xxxx devices; those commits are the canonical proof of what changed upstream. (Upstream git commit links are available in public CVE indexes and distribution advisories.
Taken together, these independent sources corroborate: (1) the precise technical fix, (2) the presence of vendor mapping into distribution kernels, and (3) that remediation is delivered as kernel-updates for affected kernel package streams.
Short, authoritative answer to the user’s question
No —
Azure Linux is not necessarily the only Microsoft product that could include the lan743x driver and therefore be potentially affected by CVE-2025-38422. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the implicated upstream component at the time of its advisory; other Microsoft-distributed kernels or images (WSL2 kernels, linux-azure kernels, Marketplace images, AKS node images, appliance images, or custom images published by partners in the Azure Marketplace) might also ship the same upstream driver depending on kernel version and build configuration until those images are explicitly inventory-checked and attested.
Practical, prioritized checklist for operators (how to validate and remediate)
- Prioritize patching Azure Linux images (if you run them)
- Apply Microsoft’s published kernel updates for Azure Linux images immediately and reboot nodes to activate the patched kernel. Microsoft’s CSAF/VEX attestation makes Azure Linux the canonical starting point.
- Inventory Microsoft-provided kernels and images in your estate
- List VMs, AKS node pools, Marketplace images, and developer machines running WSL2 or other Microsoft-published kernels.
- For each running host, collect kernel metadata: uname -r and the kernel package name.
- Check running kernels and offline images for presence of lan743x
- On a running Linux host (VM, container host, WSL), use:
- uname -r
- modinfo lan743x || lsmod | grep lan743x
- grep -R \"lan743x\" /lib/modules/$(uname -r) || zgrep CONFIG_.*LAN743X /boot/config-$(uname -r)
- If modinfo returns module metadata or /lib/modules contains lan743x objects, the driver is present on that kernel build.
- If the driver is built-in (not a module), inspect /boot/config-$(uname -r) for the compile-time option that included the driver. (Exact CONFIG_* name varies by driver — check the kernel source tree or distribution config.
- Map kernel version to upstream fix commits
- Identify the upstream commit(s) that fixed CVE-2025-38422 (these are referenced in public CVE indexes and distribution advisories).
- Compare your kernel’s vendor changelog or source/packaging information against those commit IDs to determine whether your kernel has the upstream fix or an equivalent vendor backport. On Debian/Ubuntu: apt changelog linux-image-$(uname -r); on RPM systems: rpm -q --changelog kernel | grep -i lan743x or the CVE ID.
- Update other Microsoft artifacts (WSL2, linux-azure kernels, Marketplace)
- For WSL2: check the WSL kernel version string and the published Microsoft WSL releases (or update WSL via Windows Update / WSL2 update flow). If you use a custom WSL kernel, rebuild or obtain a kernel that includes the upstream fix.
- For AKS/Marketplace images: test a VM from each marketplace/partner image and run the inspection steps above. Treat partner images as separate artifacts until the publisher attests otherwise.
- Automate CSAF/VEX ingestion
- Consume Microsoft’s machine-readable CSAF/VEX feeds as part of vulnerability management tooling. Microsoft has pledged to expand attestations beyond Azure Linux and will update VEX records when additional products are identified. Automating ingestion reduces manual reconciliation.
- Temporary mitigations (only if patching is not immediately possible)
- If the affected driver is a module, consider blacklisting the module until you can apply the kernel update. This is fragile and may disrupt device functionality.
- Avoid exposing local processes to hardware paths that probe network controllers in multi-tenant contexts until the kernel is patched.
Example commands and inspection recipes
- Identify kernel and package metadata
- uname -a
- cat /proc/version
- dpkg -l | grep linux-image (Debian/Ubuntu)
- rpm -qa | grep kernel (RHEL/CentOS)
- Check for lan743x module or built-in
- modinfo lan743x
- lsmod | grep lan743x
- grep -R \"lan743x\" /lib/modules/$(uname -r) || true
- zgrep -i \"LAN743\" /boot/config-$(uname -r) || true
- Inspect vendor changelog for CVE mapping
- Debian/Ubuntu: apt changelog linux-image-$(uname -r) | sed -n '1,200p' | grep -i 38422 -n
- RPM-based: rpm -q --changelog kernel | grep -i lan743x
- For WSL2 on Windows:
- From an elevated Windows shell: wsl --status
- Inside WSL: uname -r ; cat /proc/version ; inspect /boot/config-$(uname -r) if present
- Update WSL: wsl --update
These checks provide a deterministic, artifact-level basis for deciding whether a host or image is in scope for CVE-2025-38422 remediation.
Risk assessment: what this CVE means in practice
- Impact profile: The lan743x EEPROM/OTP-size bug is a device-driver correctness issue that can cause out-of-bounds reads or writes. In many environments this manifests as a potential denial-of-service (kernel OOPS/panic) or memory corruption; in some exploitation chains it could be leveraged toward privilege escalation if combined with other kernel vulnerabilities and favorable heap/layout conditions. Public trackers classify the fix as important; some vendor trackers scored a CVSS in the mid‑ to high‑sevens for particular packaged kernels.
- Exploitability: The bug is not a classic unauthenticated remote network worm. Exploitation generally requires local code paths that trigger the driver handling of EEPROM/OTP, access to device probe/IOCTL paths, or crafted interactions with the hardware. Clouds and multi-tenant hosts where untrusted guests could access device passthrough or SR‑IOV resources should prioritize patching.
- Where to worry most: High-availability shared hosts (hypervisors), cloud VM hosts with device passthrough, container hosts that mount hardware devices, and developer/CI machines that operate with device-level privileges. Developer laptops and single-tenant workstations are lower priority but still should be updated.
Strengths and risks of Microsoft’s attestation approach
Strengths
- Microsoft’s CSAF/VEX attestation practice increases transparency: explicitly stating which product families include a given upstream component creates deterministic signals automation can ingest, improving prioritization for customers who run those product images. The Azure Linux attestation is a valuable, machine-readable signal.
- Publishing VEX/CSAF makes vendor inventories auditable and reduces guesswork compared with vague advisories.
Risks and limits
- The attestation rollout is phased and product-scoped. That means many Microsoft artifacts remain “unknown” until individually inventoried; customers cannot assume that absence of attestation equals absence of exposure. This imposes an operational burden on defenders to perform artifact-level checks.
- A single product attestation does not directly tell you which kernel versions or package releases are fixed inside that product image family — you still need to map vendor kernel packages to upstream commits. Distribution advisories remain the practical source of package-level remediation guidance.
Final recommendations (concise and actionable)
- If you run Azure Linux images: treat Microsoft’s attestation as authoritative, apply Microsoft-published kernel updates for Azure Linux immediately, and reboot affected hosts.
- If you run other Microsoft-supplied artifacts (WSL2, linux-azure kernels, AKS/Marketplace/partner images): do artifact-level verification as outlined above; do not assume those images are unaffected just because MSRC initially attested Azure Linux only.
- For all Linux hosts: inspect whether lan743x is present (modinfo/lsmod/grep in /lib/modules), map kernel package versions to vendor advisories, and patch where vendor updates exist.
- Automate CSAF/VEX ingestion into your vulnerability management pipeline so future Microsoft updates to product attestations automatically drive reassessment and remediation.
Conclusion
CVE-2025-38422 is a real kernel-driver fix that corrects EEPROM/OTP sizing and closes an out‑of‑bounds vector in the lan743x driver. Microsoft’s public statement that
Azure Linux includes this open-source library and is therefore potentially affected is an important, machine-readable inventory claim: it is authoritative for Azure Linux and a useful signal for administrators. However, it is not a warranty that no other Microsoft artifact contains the same upstream code — other Microsoft-published kernels and images may still carry the driver until they are individually inventoried and attested. Operators should combine Microsoft’s VEX/CSAF signals with artifact-level inspection, vendor package changelogs, and distribution advisories to reach a definitive, actionable remediation plan.
Source: MSRC
Security Update Guide - Microsoft Security Response Center