The Linux kernel vulnerability tracked as CVE-2025-37997 is a narrow but meaningful race-condition bug in netfilter’s ipset hash types that was fixed upstream in 2025; Microsoft’s public attestation names Azure Linux (the Azure-distributed Linux family previously known as CBL‑Mariner) as a product that “includes this open‑source library and is therefore potentially affected,” but that attestation reflects what Microsoft has inventory‑checked so far — it is not a formal statement that no other Microsoft product could possibly include the same vulnerable code.
ipset is a kernel subsystem that provides efficient in‑kernel sets of IP addresses, networks, ports, or combinations used by iptables/nftables rules. It’s widely used in firewalls, rate‑limiting, DHCP/connection tracking helpers, and various network‑filtering workflows where maintaining large sets of IPs efficiently is required. The CVE in question affects the ipset hash types when those sets are created with timeouts and the kernel code’s region locking macros were implemented incorrectly, producing a race between garbage‑collection and element insertion. The flaw was introduced in the ahash/region locking changes around v5.6-rc4 and the upstream fixes were merged into the stable kernel trees and downstream vendor kernels.
Technically, the bug stems from an incorrect implementation of the macro that maps a hash bucket to its region lock (ahash_region()). Because the mapping was wrong, concurrent operations — specifically the garbage collector cleaning out timed‑out elements while another thread inserts a new element — could race in a way that breaks internal invariants. Practically, that can result in data corruption or resource exhaustion in the kernel’s ipset structures and therefore availability problems (crashes, kernel memory corruption, or denial‑of‑service), rather than an obvious direct escalation to remote code execution in the common case. Vendor trackers and advisories placed the issue at medium severity with exploitability constrained by local/low‑privilege conditions and specific usage scenarios.
It is important to read that wording precisely: Microsoft attested an inventory result for a named product family (Azure Linux). That attestation tells you, authoritatively, that Azure Linux is in scope as of Microsoft’s inventory cut. It does not prove that other Microsoft‑shipped Linux artifacts are absent of the vulnerable code. In other words: Azure Linux is the only Microsoft product Microsoft has publicly attested as including the component — so far; absence from the public attestation is not evidence that other Microsoft artifacts do not contain the vulnerable code. Security teams must treat absence of attestation as “not yet confirmed” rather than “not affected.”
Patch (preferred)
Practical advice:
Act now: inventory kernels, prioritize updates for multi‑tenant or ipset‑heavy systems, and apply vendor patches as they arrive. Azure Linux customers can rely on Microsoft’s VEX/CSAF attestations for that product today — but everyone should still do the hard work of independent inventory and patching across their environment.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
ipset is a kernel subsystem that provides efficient in‑kernel sets of IP addresses, networks, ports, or combinations used by iptables/nftables rules. It’s widely used in firewalls, rate‑limiting, DHCP/connection tracking helpers, and various network‑filtering workflows where maintaining large sets of IPs efficiently is required. The CVE in question affects the ipset hash types when those sets are created with timeouts and the kernel code’s region locking macros were implemented incorrectly, producing a race between garbage‑collection and element insertion. The flaw was introduced in the ahash/region locking changes around v5.6-rc4 and the upstream fixes were merged into the stable kernel trees and downstream vendor kernels.Technically, the bug stems from an incorrect implementation of the macro that maps a hash bucket to its region lock (ahash_region()). Because the mapping was wrong, concurrent operations — specifically the garbage collector cleaning out timed‑out elements while another thread inserts a new element — could race in a way that breaks internal invariants. Practically, that can result in data corruption or resource exhaustion in the kernel’s ipset structures and therefore availability problems (crashes, kernel memory corruption, or denial‑of‑service), rather than an obvious direct escalation to remote code execution in the common case. Vendor trackers and advisories placed the issue at medium severity with exploitability constrained by local/low‑privilege conditions and specific usage scenarios.
What Microsoft actually said — and what that means
Microsoft’s public messaging around this CVE takes the form of a product‑level attestation: the company has identified that the Azure Linux Distribution (the Microsoft‑published Azure distro lineage) includes the vulnerable open‑source component and therefore Azure Linux is potentially affected. Microsoft also explained that beginning in October 2025 it published machine‑readable CSAF/VEX attestations for Azure Linux as part of a phased approach to disclosing third‑party vulnerability status; Microsoft will update the CVE/VEX record if additional Microsoft products are later found to ship the affected code. That commitment is meaningful: it provides automation‑friendly signals to Azure Linux customers and is intended to grow to cover more Microsoft products over time.It is important to read that wording precisely: Microsoft attested an inventory result for a named product family (Azure Linux). That attestation tells you, authoritatively, that Azure Linux is in scope as of Microsoft’s inventory cut. It does not prove that other Microsoft‑shipped Linux artifacts are absent of the vulnerable code. In other words: Azure Linux is the only Microsoft product Microsoft has publicly attested as including the component — so far; absence from the public attestation is not evidence that other Microsoft artifacts do not contain the vulnerable code. Security teams must treat absence of attestation as “not yet confirmed” rather than “not affected.”
Which Microsoft products could ship the affected code?
The ecosystem of Microsoft‑shipped Linux artifacts is broader than a single distribution. These items are plausible carriers of the same ipset code, depending on kernel version and build configuration:- Azure Linux (CBL‑Mariner lineage / Azure Linux Distribution) — Microsoft has explicitly attested this product family as including the component and therefore potentially affected. Microsoft published VEX/CSAF attestations for this family as part of its transparency rollout.
- linux‑azure kernels and Azure VM kernels (Ubuntu’s linux‑azure packaging for Azure VMs) — kernel packages built for the Azure host environment (linux‑azure) and the kernel variants used on Azure VMs are tracked by distribution vendors and already show the CVE in release notes and SRUs; these kernels are a practical conduit for the upstream ipset code into Azure guest images. Ubuntu’s linux‑azure tracks CVE‑2025‑37997 in its changelogs and package trackers.
- CBL‑Mariner artifacts used inside Microsoft infrastructure — CBL‑Mariner (now represented within Azure Linux family artifacts) is used as a base image and container host in some Azure offerings; CBL‑Mariner security trackers and third‑party CVE mappings list the kernel vulnerability and patch status. Tooling that maps CVEs to Microsoft’s product trees shows Azure Linux/CBL‑Mariner relationships.
- Windows Subsystem for Linux (WSL2) kernel — WSL2 ships a Microsoft‑maintained Linux kernel binary for guests; that kernel is public in the microsoft/WSL2‑Linux‑Kernel repository and is built from a Microsoft‑managed kernel tree. Community and published WSL kernel configuration files for “config‑wsl” include ipset options (CONFIG_IP_SET and associated module flags), which demonstrates that the WSL2 kernel can and commonly does include ipset support as modules. That makes WSL2 a plausible carrier of the same ipset code depending on the kernel version shipped by Microsoft. (github.com)
- Other Microsoft Linux artifacts or appliances — Microsoft ships or uses Linux components across a wide range of services (container hosts, managed nodes, telemetry agents, IoT/edge artifacts) and any of those could incorporate upstream kernel sources or kernel modules that include ipset, depending on build choices.
How the vulnerability maps to real‑world risk
- Threat model: The defect is a concurrency/race issue in an in‑kernel data structure. The most likely attack vector is a local, low‑privileged user or untrusted workload that can interact with ipset APIs (via ipset tool, libipset, nftables/iptables rules, or netlink) on a system where ipset hash types with timeouts are used. In multi‑tenant or container hosting scenarios, an unprivileged tenant might be able to induce the race by creating and manipulating ipset sets, increasing the attack surface.
- Typical impact: Memory corruption, kernel data structure inconsistency, or denial‑of‑service (kernel oops/panic or uncontrolled resource growth). Most vendor advisories characterize the primary impact as availability rather than remote code execution. Exploitation to escalate privileges or achieve sandbox escape would require additional, uncommon conditions.
- Environments of highest concern:
- Cloud multi‑tenant hosts and container nodes where tenants share kernel resources.
- Systems that rely on ipset‑backed firewalling at scale (large sets, frequent timeouts).
- Systems where unprivileged users or workloads are allowed to create or modify ipset sets.
What to check in your environment (practical inventory steps)
If you manage systems that run on Microsoft infrastructure or include Microsoft‑shipped Linux artifacts, run the following checks immediately:- Identify kernels and distributions in use:
- Check the kernel version string (uname -r) and map it to vendor advisories (Ubuntu, Debian, SUSE, Oracle, CBL‑Mariner, etc.). Vendor trackers already map the upstream fix into distribution kernels.
- Check for ipset support in your running kernel and whether ipset modules are loaded:
- lsmod | grep ip_set
- modinfo ip_set_hash_ip (or check /lib/modules/$(uname -r)/kernel/net/netfilter/ipset)
- ipset list (to see active sets) and ipset --version to confirm presence of the userland tool.
- Audit firewall and container setups for ipset usage:
- Search iptables/nftables rules for references to set names.
- Inspect container images and init scripts for ipset usage; ephemeral containers that create ipsets may still require kernel support.
- For WSL2 users and administrators:
- Note that WSL2 uses a Microsoft‑published kernel. If you run workloads inside WSL2 that manipulate kernel ipset objects or run untrusted code, treat WSL2 as a potential carrier and watch for kernel updates from the WSL project. Community and shared config files show ipset options in the WSL kernel config.
- For Azure customers:
- Check the image kernels you use in Azure (marketplace images, custom images) and the distro kernels (linux‑azure packages, cloud kernels) for updated packages that include the ipset fix. Ubuntu’s linux‑azure changelogs explicitly included the fix in the tracked linux‑azure kernel packages.
Immediate mitigations and remediation options
There are three complementary paths you should consider: patch, reduce attack surface, and detect.Patch (preferred)
- Apply vendor kernel updates as soon as vendor packages that include the upstream ipset fix are available for your distribution and kernel variant. Upstream and distribution trackers (Ubuntu, Debian, SUSE, Oracle, etc.) list the fix and map it to package versions — prefer vendor kernels rather than hand‑patching.
- Remove or blacklist ipset kernel modules if your workloads do not need them:
- rmmod ip_set_hash_ip ip_set ip_set_list_set (module names vary)
- Add blacklist entries to modprobe.d to prevent future loads.
- This will break any functionality that depends on ipset; test before removal.
- Prevent untrusted workloads or tenants from creating ipset sets:
- Enforce stricter container runtime privileges; deny CAP_NET_ADMIN to untrusted containers.
- Disallow unprivileged users from invoking ipset or netlink‑based management.
- For WSL2 users who cannot immediately get a WSL kernel update, avoid running untrusted code that manipulates ipset objects inside WSL2. Microsoft distributes WSL kernel updates; monitor the WSL project for updated kernels. (github.com)
- Monitor dmesg/syslog for kernel oopses or ipset‑related errors.
- Add host or container‑level detection rules to flag frequent ipset manipulations or unusual netlink traffic.
- Use kernel livepatch solutions where supported (kpatch/ktap/livepatch for supported vendor kernels) to reduce downtime — note that livepatch availability depends on vendor support.
How to interpret Microsoft’s CSAF / VEX attestation program
Microsoft’s CSAF/VEX rollout is intended to provide machine‑readable attestations that answer “Does this Microsoft product ship the vulnerable third‑party component?” — with options like Not Affected, Under Investigation, Known Affected, or Fixed. The company started the program with Azure Linux (the product family easiest to inventory first) and committed to extend coverage. That procedural approach is helpful for automation, but it also means that a product’s absence from the VEX feed is not a proof of absence — it may simply mean the product hasn’t been fully inventory‑checked and attested yet. Security teams should use Microsoft’s VEX/CSAF data as a trusted positive (if Microsoft says “Known Affected” for Azure Linux, treat it as in scope) and as a helpful signal, but not as the exclusive source of truth for all Microsoft‑shipped Linux artifacts.Practical advice:
- Automate ingestion of Microsoft’s CSAF/VEX feeds if you operate Azure Linux artifacts. Use those attestations as authoritative for automation.
- Independently inventory other Microsoft artifacts you use (WSL kernels, marketplace images, container host images). Don’t rely solely on the initial VEX phase for complete coverage.
- Expect Microsoft to update the VEX feed for additional products if their internal inventories discover carriers of the affected code; but keep your own inventory and patching pipeline in sync regardless.
What defenders and IR teams need to know
- Prioritize systems that are multi‑tenant, run untrusted workloads, or rely heavily on ipset for network controls. Those environments have the highest risk amplification.
- A local, low‑privilege actor is the most credible threat model; in cloud or container environments, tenant isolation failures or overly permissive privileges increase risk.
- Because the bug is concurrency‑based, exploitation may be noisy and can cause instability — monitoring and alerting on kernel OOPS, panic, or repeated restarts is critical.
- For compliance and disclosure: If you operate Azure Linux in production, Microsoft’s VEX attestation gives you a machine‑readable record for your SBOM/Vulnerability Management processes. For other Microsoft artifacts, document your independent findings.
A short technical note for kernel/OS maintainers
The upstream fix is small and focused: correct the ahash_region() mapping so the region lock computed for a given bucket is correct, eliminating the race between the garbage collector and element insertion for timed hash types. Distribution maintainers mapped that change into stable tree backports and released kernel package updates. If you maintain custom kernels (e.g., internal images, custom WSL kernels), follow stable upstream and apply the specific patches referenced in the upstream commits rather than attempting ad‑hoc reworks. Upstream commit references were included in OSV and vendor tracker entries for CVE‑2025‑37997.Bottom line and recommended action plan (for IT teams)
- Treat Microsoft’s Microsoft Security Response Center (MSRC) attestation for Azure Linux as authoritative for that product family — patch Azure Linux images running in your environment promptly when vendor kernels are available.
- Do not assume absence of risk for other Microsoft artifacts (WSL2 kernels, linux‑azure guests, container hosts). Independently inventory and check:
- Which kernel versions you run (uname -r).
- Whether ipset modules are present and in use.
- Whether untrusted workloads can manipulate ipset sets.
- Apply vendor kernel updates where available; if you cannot patch quickly:
- Consider unloading/blacklisting ipset modules if safe to do so.
- Harden privilege boundaries (CAP_NET_ADMIN restrictions for containers, restrict access to netlink/ipset utilities).
- Monitor Microsoft’s CSAF/VEX feed and vendor security advisories, but use them as one signal among others — absence of a VEX attestation for a product does NOT prove the product is unaffected. Microsoft’s phased rollout means attestations will expand over time.
- Document your remediation decisions and detection coverage for future audits and incident readiness.
Final assessment
CVE‑2025‑37997 is not the most severe kernel vulnerability in the wild, but it is a real correctness and availability defect that affects a widely used kernel subsystem under specific conditions. Microsoft’s transparency effort — publishing CSAF/VEX attestations starting with Azure Linux — gives Azure customers an important automation‑friendly signal and a clear remediation path for that product family. However, security teams should avoid interpreting Microsoft’s initial attestation as a comprehensive statement about every Microsoft‑shipped Linux artifact. Other Microsoft kernels and artifacts (notably the WSL2 kernel and various cloud‑targeted kernels such as linux‑azure and CBL‑Mariner derived images) are plausible carriers of the same upstream ipset code depending on build choices, and should therefore be inventoried, patched, or mitigated proactively.Act now: inventory kernels, prioritize updates for multi‑tenant or ipset‑heavy systems, and apply vendor patches as they arrive. Azure Linux customers can rely on Microsoft’s VEX/CSAF attestations for that product today — but everyone should still do the hard work of independent inventory and patching across their environment.
Source: MSRC Security Update Guide - Microsoft Security Response Center
