CVE-2025-37755: Azure Linux attestation and libwx kernel NULL-pointer risk

Microsoft’s published advisory on CVE-2025-37755 correctly identifies a kernel-level NULL-pointer handling bug in the Linux net subsystem (the libwx codepath) — but the phrasing that “Azure Linux includes this open‑source library and is therefore potentially affected” is an attestation for a specific product inventory, not a technical guarantee that no other Microsoft product could ship the same vulnerable code.

Background / Overview​

CVE-2025-37755 describes a NULL‑pointer dereference in the Linux kernel networking code associated with the libwx library used by the Wangxun family of Ethernet drivers. The immediate technical symptom is that the helper function page_pool_dev_alloc_pages can return NULL, the code triggers a WARN_ON(!page) and then continues to use the pointer, which can lead to a kernel crash. Upstream maintainers fixed this class of error by adding proper NULL checks and adjusting error paths; the fix was merged to the stable kernel trees and is present in later stable releases and vendor backports.
The vulnerability is assessed as a moderate severity issue in typical trackers (CVSS v3 ≈ 5.5). The attack model is local: a user or local process with the ability to exercise the affected driver code can provoke a kernel panic or DoS by triggering the NULL dereference. There are no widely reported remote exploitation scenarios that turn this specific bug into remote code execution; the principal impact is availability (kernel crash).
Microsoft’s public messaging for this and many other Linux-kernel CVEs has emphasized two points:

• Azure Linux (the Microsoft-maintained distro derived from CBL‑Mariner) is a confirmed product that ships the implicated upstream component, and Microsoft has published CSAF/VEX attestations starting with Azure Linux.
• Microsoft will expand its published VEX/CSAF attestations over time; if other Microsoft products are discovered to ship the same upstream component, Microsoft will update its CVE mapping accordingly.

That phrasing answers the immediate customer question: Azure Linux is a confirmed hit in Microsoft’s inventory. But it does not, on its own, prove that other Microsoft-distributed kernels, images, or artifacts are free of the vulnerable libwx code — those artifacts must either be attested by Microsoft or inspected locally to be certain.

---

What the bug actually is — technical breakdown​

The vulnerable code path​

• The problem originates in drivers/net/ethernet/wangxun/libwx, a shared library used by several Wangxun Ethernet driver modules (for example, txgbe/ngbe families and the libwx helper module).
• The helper function page_pool_dev_alloc_pages (or similarly named internal allocator code) can return NULL under low-memory or allocation failure conditions.
• The code originally emitted a WARN_ON(!page) but continued execution, dereferencing the NULL pointer; this leads to an immediate kernel oops/panic when the code attempts to use the page pointer.

Root cause category​

• This is a classic NULL pointer dereference / missing error-path handling bug (CWE-476). The code didn’t handle the allocator’s failure return path and proceeded as if the allocation had succeeded.

Practical impact​

• Attack vector: local (requires the ability to interact with the network driver or exercise a network device bound to the Wangxun driver).
• Effect: denial of service / crash of the kernel; in production systems this manifests as process/kernel instability, reboots, or service downtime.
• Exploitability: low for remote threats, higher for local privilege-limited scenarios (an unprivileged local user who can issue crafted packets or manipulate a device bound to the driver may be able to trigger the condition).

---

Microsoft’s statement and what it means in practice​

Microsoft’s advisory language — noting Azure Linux as a product that “includes this open‑source library and is therefore potentially affected” — is a deliberate, product‑scoped attestation. Practically this implies:

• Authoritative attestation for Azure Linux: Microsoft has completed an inventory for its Azure Linux product line and can say with confidence that those Azure Linux builds include the upstream component in question. For Azure Linux customers, that statement is actionable: treat the product as potentially affected until it has been patched and attestations are updated to “Fixed.”
• Phased disclosure model: Microsoft started publishing machine‑readable CSAF and VEX attestations in October 2025 and is rolling out product-specific VEX mappings. The fact that other Microsoft products are not currently listed as “affected” is not proof they cannot be affected — it may simply mean Microsoft has not yet completed the inventory for those products.
• What customers should infer: Azure Linux is a confirmed product to check and patch. Other Microsoft-distributed kernel artifacts (for example, WSL kernels, certain Azure marketplace images, or custom images maintained by Microsoft) could include the same upstream drivers depending on kernel version and kernel configuration; verify those artifacts directly.

---

Are other Microsoft products likely to include libwx?​

Short answer: Possibly. Longer, practical answer: you cannot assume “not affected” for other Microsoft products just because Microsoft named Azure Linux first.
Why:

• The presence of the Wangxun libwx code in a delivered kernel depends on two independent factors: the kernel version used for that build, and the kernel configuration (Kconfig flags) chosen at compile time.
• Several Microsoft-distributed kernel artifacts exist beyond Azure Linux: WSL/WSL2 kernels, various Azure kernel images used in VM offerings, and kernel images shipped in other Microsoft-managed services or marketplace images. Any of those artifacts that use a kernel version and configuration which includes drivers/net/ethernet/wangxun or CONFIG_LIBWX could be affected.
• Microsoft’s initial VEX/CSAF rollout deliberately focused on Azure Linux to produce accurate attestations for at least one product family first. Microsoft’s public promise is to update the CVE/VEX entry as additional product inventories are completed.

Therefore, do not treat the absence of an attestation for another Microsoft product as proof that it does not contain the vulnerable code. Verify.

---

How to determine if your systems (including Microsoft-provided artifacts) are affected​

You must check each running kernel image or provided kernel artifact. The presence of the vulnerable code can be determined quickly by checking kernel configuration and loaded modules.
Here are practical checks operators and administrators should run:

• Check the kernel config for the libwx option
• Look for a file named /boot/config-$(uname -r) or /proc/config.gz on the running system.
• Search for Kconfig options:
• CONFIG_LIBWX
• CONFIG_TXGBE, CONFIG_NGBE, CONFIG_TXGBEVF, CONFIG_NGBEVF
• If CONFIG_LIBWX is set to y or m, the libwx helper is present (built‑in or modular).
• Check loaded modules and device driver files
• List loaded modules for Wangxun drivers or libwx:
• Example command (run as root): lsmod | grep -E 'libwx|txgbe|ngbe|wx'
• Inspect /lib/modules/$(uname -r) for modules matching wangxun, txgbe, ngbe, libwx.
• For Microsoft-supplied artifacts (WSL, Azure VM images, marketplace images)
• WSL: run uname -r inside WSL and then check the kernel config in /proc/config.gz or the build artifact shipped by Microsoft; use the official WSL update flow to ensure kernel is current.
• Azure VM images / Marketplace images: check the kernel package version and vendor changelogs; for images you control, boot an instance and run the above checks.
• If you manage images centrally (e.g., custom marketplace images, snapshots), examine the kernel build configuration used when the image was built.
• Look for symptomatic logs
• dmesg output containing WARN_ON(!page) traces from libwx or driver tracebacks are an immediate red flag that the code path was executed and a NULL-handling path triggered.
• Kernel crash logs and kdump output can show the backtrace pointing to drivers/net/ethernet/wangxun/libwx/*.

Note: If you cannot access the running kernel config (for example, because an image is static and you only receive the tarball), treat the image as unknown and verify via a test boot or by querying the vendor’s attestation.

---

Remediation and mitigation recommendations​

The long‑term fix is to update the kernel to a version that includes the upstream patch (or to apply the vendor backport). Practically, follow a layered approach:

• Immediate operational mitigations
• Reduce local attack surface: restrict shell or container access for untrusted users. Limit who can interact with the host’s network devices.
• Monitor and alert: watch dmesg/syslog for WARN_ON messages referencing page_pool_dev_alloc_pages or libwx and configure alerts for kernel oops/panic patterns.
• Enable crash capture: configure kdump or an equivalent crash collection service to capture crash dumps for forensic analysis if the bug is triggered.
• Apply vendor/kernel updates (primary remediation)
• Identify whether your installed kernel is in the affected range by mapping your kernel version to the upstream fixes.
• For Azure Linux: follow Microsoft’s update guidance and apply the vendor-released kernel packages or image updates when published.
• For distribution-maintained kernels (Ubuntu, SUSE, RHEL derivatives): apply the security/kernel updates delivered by the distro maintainers; those packages already include upstream fixes or vendor backports.
• For WSL users: use the official WSL update mechanism (for example, the wsl --update flow or the Microsoft-provided kernel package) to get the patched kernel if Microsoft has released an updated WSL kernel.
• For custom-built kernels: merge the upstream patch commits into your kernel tree and rebuild. Ensure your kernel config does not select libwx unless the hardware requires it.
• Where live patching is possible
• If your environment supports live kernel patching technologies (for example, vendor livepatch services), check whether a livepatch addressing this specific issue is available and apply it as a stopgap until a full reboot/patched kernel can be scheduled.
• Longer-term hardening
• When building kernels for deployment, remove unnecessary drivers by disabling corresponding Kconfig options (for example, unset CONFIG_LIBWX and related TXGBE/NGBE options) unless you run hardware that needs them.
• Establish a formal inventory and SBOM-like mapping for kernel subsystems used by your images so you can quickly map upstream CVEs to deployed artifacts.

---

Detection and monitoring guidance​

• Add a kernel log check for the specific warning text frequently emitted by this class of bug (kernel WARN_ON messages mentioning page_pool_dev_alloc_pages or libwx).
• Add integrity checks for /boot/config-* and module lists; alert when a new kernel that includes CONFIG_LIBWX is deployed.
• For cloud environments, include ephemeral image scanning in your CI pipeline: when building or publishing an image, check the kernel configuration as part of image validation.
• For WSL/endpoint users: integrate WSL kernel version checks into endpoint vulnerability scanning — the WSL kernel is a special artifact that vendors sometimes update outside general package updates.

---

Practical advice for different user personas​

• Azure Linux (CBL‑Mariner) operators: treat the MSRC attestation as authoritative and apply Microsoft’s Azure Linux kernel updates as soon as they are available. Confirm the VEX/CSAF attestation for status changes from “Known Affected” to “Fixed” before declaring hosts remediated.
• WSL / Developer machines: run the supplied WSL update mechanism and verify the kernel version inside WSL. If you have custom WSL kernels, rebuild with the upstream patches or switch to the vendor-supplied kernel image.
• Cloud operators using Microsoft Marketplace images: do not assume a Marketplace image is unaffected. Boot a test instance and check the kernel config / module list; apply vendor patches or refresh images as necessary.
• Enterprise security teams: include kernel configuration checks (CONFIG_LIBWX and related Kconfig entries) in vulnerability management playbooks and SBOMs for Linux kernel artifacts.

---

Risk analysis — strengths and potential gaps​

• Strengths
• The technical fix is straightforward: add appropriate NULL-checks and correct error-handling paths. Upstream fixes merged to stable branches are available, and vendor distributions have already packaged patches in many cases.
• Microsoft’s decision to publish machine-readable VEX/CSAF attestation for Azure Linux improves transparency and gives customers clear, actionable information for that product family.
• The vulnerability’s local-only attack vector reduces the immediacy of remote, large-scale exploitation.
• Potential gaps / risks
• Inventory blind spots: Large vendors ship many kernel artifacts. A product‑scoped attestation for Azure Linux leaves the possibility that other Microsoft-distributed kernels (WSL, specialized Azure kernel builds, baked-in kernel images inside appliances) may still include the vulnerable code until they are explicitly attested or patched.
• Image fragmentation: Cloud environments and vendor marketplaces produce numerous derived images. Customers who rely on partner or third‑party images must validate those images independently; vendor attestation is not a substitute for private inventory checks.
• Operational constraints: Many production systems have long maintenance windows; if an exploit can be triggered locally by an unprivileged user, this creates an operational urgency that some organizations may not comfortably meet within typical change windows.
• Detection difficulty: Unless dmesg and kdump are actively monitored, a triggered kernel oops may be missed or attributed to transient instability. Without comprehensive monitoring, this can delay detection and response.

---

Recommended checklist for IT/security teams (immediate steps)​

• Inventory all kernels and kernel artifacts you run (servers, containers where full kernels are shipped, WSL on endpoints, Azure Marketplace images).
• For each kernel, verify /boot/config-* for CONFIG_LIBWX, CONFIG_TXGBE, CONFIG_NGBE, CONFIG_TXGBEVF, CONFIG_NGBEVF.
• If any image or kernel is found to include the Wangxun drivers or libwx helper, schedule immediate patching with the vendor update or plan to rebuild the kernel with the upstream fixes applied.
• Enable and monitor kernel logging for WARN_ON messages tied to libwx and page_pool_dev_alloc_pages.
• Where possible, limit local access and untrusted user capabilities on hosts that cannot be immediately patched.
• Subscribe to vendor attestations (MSRC CSAF/VEX for Microsoft products, distro security advisories) and confirm the change of status from “Known Affected” to “Fixed” for each product of interest.

---

Final takeaways​

• Microsoft’s advisory naming Azure Linux as a product that includes the libwx component is an important, authoritative data point for that product family — treat Azure Linux as confirmed and follow Microsoft’s remediation guidance for those images.
• However, Azure Linux is not categorically the only Microsoft artifact that could include the vulnerable code. Presence or absence in other Microsoft products is an artifact-specific technical question driven by kernel version and compile-time configuration — and Microsoft’s initial VEX rollout intentionally started with Azure Linux as a first attested product.
• The safest posture for any operator is to assume any kernel image delivered by Microsoft or by third parties could contain the vulnerable driver until you verify the kernel configuration or see a published attestation declaring “Not Affected” or “Fixed.”
• Practically, patching the kernel (or applying vendor backports) is the definitive remedy. In parallel, implement monitoring, reduce local attack surface, and establish an inventory-driven process to map upstream CVEs to deployed artifacts so future kernel-level issues can be triaged rapidly.

CVE-2025-37755 is a reminder that kernel-level supply‑chain and configuration details matter: a patch in upstream Git is only protective when the exact kernel builds you run are updated or rebuilt to include the fix. Treat vendor attestations as authoritative for the product they name, but verify your own artifacts.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center