CVE-2025-38477 Linux sch_qfq Race Condition and Azure Linux Attestation

A race in the Linux packet scheduler has produced a quietly serious kernel advisory: CVE-2025-38477 patches a race condition in the net/sched sch_qfq implementation that can lead to NULL dereferences and use‑after‑free behavior, and Microsoft’s public advisory names Azure Linux as a confirmed carrier of the upstream component while explicitly reserving the right to expand that attestation to other Microsoft products as inventory work completes.

Background / Overview​

The affected code lives in the Linux kernel’s network scheduler subsystem — net/sched — specifically the Quick Fair Queueing (QFQ) implementation exposed as sch_qfq. QFQ is a packet scheduling discipline (qdisc) intended to provide fair queuing behavior with scalability benefits for certain traffic-shaping use cases. The implementation can be built into kernels or compiled as a loadable module (typically exposed as sch_qfq.ko).
CVE-2025-38477 was publicly recorded in late July 2025 and appears in vendor advisories and distro trackers through the subsequent months. The change that fixes the bug moves destruction of a class into an existing critical section and adds tree-level locking around qfq dump operations to prevent concurrent access to an aggregate (agg) structure while other threads may be modifying it. In short, the upstream fix synchronizes access so one thread cannot observe or free state another thread is changing.
Microsoft’s public update guidance for this CVE includes an FAQ note that reads, in effect: Microsoft has verified that Azure Linux includes the implicated open‑source component and is therefore potentially affected, and the company began publishing machine‑readable CSAF/VEX attestations in October 2025; Microsoft will update the CVE entry if additional Microsoft products are identified as affected. That language is a product‑level attestation for Azure Linux — it confirms Azure Linux is a known carrier and promises phased expansion of attestations, but it does not amount to a categorical guarantee that no other Microsoft artifact contains the same kernel code.

---

What the bug actually does — technical summary​

• The problem is a race condition in sch_qfq where the pointer to an aggregate (often named agg) can be changed by one thread while another thread is simultaneously reading it.
• The race is observable in operations such as:
• qfq_enqueue / qfq_change_agg (path that may reassign agg)
• qfq_dump_class (reporting code that reads fields on agg)
• qfq_delete_class (which destroys class state)
• Observable outcomes reported by kernel maintainers and vendor advisories:
• NULL pointer dereference during diagnostic/dump paths (leading to kernel oops/panic).
• Use‑after‑free when qfq_destroy_class runs concurrently with other readers — a classic concurrency bug.
• The upstream fix (the official patch) does two things:
• Move qfq_destroy_class into the critical section so destruction cannot race with readers.
• Protect qfq_dump_class and qfq_dump_class_stats with sch_tree_lock to prevent concurrent access to agg.

Severity and exploitation characteristics

• The vulnerability is local — it requires actions on the host, often needing administrative networking capability (many vendor advisories indicate the attack requires CAP_NET_ADMIN or equivalent privileges).
• Impact is primarily denial‑of‑service / kernel crash via NULL dereference; vendors report that privilege escalation is not a straightforward outcome because the bug does not appear to provide a write primitive or control over function pointers in a way that reliably leads to code execution.
• Vendors have rated the issue moderate to high for local crash potential depending on distro/kernel packaging; stable‑tree and vendor backports followed quickly after the upstream patch.

---

Why Microsoft named Azure Linux — reading the MSRC wording correctly​

Microsoft’s advisory language that “Azure Linux includes this open‑source library and is therefore potentially affected” should be read as a product‑scoped attestation — Microsoft checked the Azure Linux build artifacts and found the upstream kernel subsystem in those images, so Azure Linux is a confirmed hit for customers who run those images.
That statement is intentionally narrow:

• It is authoritative and actionable for Azure Linux customers — treat Azure Linux images as impacted until they receive the backported fix from Microsoft or the distro package maintainers.
• It is not an exclusive assertion that no other Microsoft product contains the same code. Microsoft explicitly promises to update the CVE/VEX mapping as it discovers additional Microsoft artifacts that ship the vulnerable upstream component.
• In practice, large vendors verify and publish attestations in phases: start with product families that are fully inventoried (Azure Linux was a natural first wave for Microsoft), then expand.

Put bluntly: Azure Linux is the only Microsoft product Microsoft has publicly attested to include the sch_qfq component for this CVE at the time of the advisory, but that is not proof that other Microsoft products are unaffected. System owners must treat other Microsoft artifacts as unverified until Microsoft publishes attestations or until the artifact is inspected locally.

---

Which other Microsoft products might plausibly include the same code?​

Microsoft ships and maintains Linux kernel artifacts in several distinct places. Any of the following can, depending on kernel version and configuration, include the sch_qfq implementation and therefore could be affected if they use a kernel version older than the fixes:

• Windows Subsystem for Linux (WSL / WSL2)
  Microsoft publishes a maintained WSL2 kernel tree and ships WSL kernels as part of the WSL component. The repository and release tags show WSL kernels are based on stable upstream branches and include many standard kernel subsystems. Whether a specific WSL kernel build includes sch_qfq depends on the chosen kernel config and release tag.
• Azure Marketplace images and custom VM images
  Many Azure VM images include vendor or Microsoft-supplied kernel packages. If a Marketplace image or a custom VM image includes a kernel build older than the fixed upstream commits and has QFQ enabled, it could be affected.
• Azure Kubernetes Service (AKS) node OS images and container host images
  Node images and container hosts may use kernels derived from vendor trees; they must be validated per‑image.
• Other Microsoft Linux artifacts
  This includes Microsoft‑maintained distributions (for example Azure Linux / CBL‑Mariner family), any kernel packages Microsoft supplies for specific Azure services, and specialized appliances or platform images that embed a Linux kernel.

Important operational point: presence of the upstream source file (or compiled module) is an artifact-specific property. Two kernels from the same vendor can differ: one may have CONFIG_NET_SCH_QFQ=y or m, another may have it disabled. Only artifact-level inspection or an explicit product attestation shows whether the component is present.

---

Practical guidance: inventory, detection, and immediate mitigations​

Operators must perform three things quickly: (1) identify which images/kernels you run that may include sch_qfq; (2) establish whether the kernel version includes the upstream fixes; (3) apply vendor-supplied updates (or mitigations) promptly.
Use these commands and checks as a short runbook. Run locally on each host or on a representative sample of images used in your environment.

Quick discovery commands (run on the target host)​

• Show running kernel:
• uname -r
• Check kernel config for QFQ (two common locations):
• zcat /proc/config.gz | grep CONFIG_NET_SCH_QFQ
• grep CONFIG_NET_SCH_QFQ /boot/config-$(uname -r)
• If you see CONFIG_NET_SCH_QFQ=y (built-in) or =m (module), the QFQ subsystem is present.
• Look for the module on disk (if modules are used):
• ls /lib/modules/$(uname -r)/kernel/net/sched | grep qfq
• modinfo sch_qfq (returns module info if the module exists)
• Check for the qdisc at runtime:
• tc qdisc show
• tc -s qdisc show (gives statistics — if QFQ is loaded and used it may appear here)
• For WSL instances:
• Inside WSL: uname -r (to get the kernel version string)
• From Windows host: wsl --status and wsl --update to confirm WSL kernel servicing method

How to quickly mitigate (if you must act before a vendor patch is available)​

• Patch promptly: the correct mitigation is to upgrade the kernel to a vendor-supplied package that contains the backport/patch.
• Short‑term module blacklist (mitigation when module is loadable and you can tolerate losing QFQ qdisc):
• Add blacklist entry (example for immediate mitigation):
• Create file /etc/modprobe.d/blacklist-sch_qfq.conf with content: blacklist sch_qfq
• Regenerate initramfs if needed for your distro and reboot (or make sure the module is not loaded).
• If module is already loaded: sudo rmmod sch_qfq (only safe when qdisc is unused; rmmod will fail if in use)
• Network policy / capability restrictions: limit which local users or containers have CAP_NET_ADMIN in your environment — the reported exploit scenarios require network administrative capability.
• For WSL: apply WSL updates via Windows Update / the wsl tooling (wsl --update) or use a custom patched kernel if you maintain one.

Caveats:

• Blacklisting the module removes QFQ functionality and may break traffic shaping that depends on it.
• Some kernels have QFQ built-in (CONFIG_NET_SCH_QFQ=y), in which case module blacklisting is not possible; patching the kernel or upgrading the package is necessary.

---

Mapping kernel versions to the fix — how to know when you’re safe​

Vendors backported the upstream fix into their kernel packages. Fixed package versions vary by distribution and kernel branch; examples of vendor fixes (illustrative list, not exhaustive):

• Debian/Ubuntu packages show fixes in vendor kernels such as:
• 5.10.244-1 (backport for older LTS)
• 6.1.147-1 and 6.1.153-1 (stable 6.1 branch backports)
• 6.12.41-1, 6.12.48-1 (6.12 branch)
• 6.16.3-1 (6.16 branch)
• Vendor stable-tree and enterprise vendors (Red Hat, Oracle, Amazon, SUSE) published kernel advisories and package updates for their supported releases that include the upstream patch.

How to determine whether a specific kernel build is patched:

• Compare the running kernel version/release string (uname -r) with vendor advisories and the fixed package versions. Vendors list the fixed kernel package names and release numbers in their advisories.
• If an image is using a vendor-provided kernel (Azure Marketplace, RHEL, Ubuntu, SUSE), check the vendor advisory and apply the recommended kernel update.
• For custom kernels (including some WSL custom builds), you may need to inspect the kernel git history or the included commit range. Look for the upstream commit that implements the qfq fix in the stable tree; if your kernel includes that commit (or a backport) you are patched.

If you cannot find a direct mapping for a given kernel string, treat the artifact as unverified and schedule an update or rebuild with a known patched upstream state.

---

Risk analysis: who should worry, and how urgently​

• Azure Linux (Microsoft‑attested): treat as confirmed carrier. If you run Azure Linux images in production or dev, apply the updates Microsoft supplies or patch images from your private image pipeline as soon as vendor packages are available.
• WSL2 users: WSL ships a Microsoft‑maintained kernel tree; many WSL builds track upstream stable branches and include standard schedulers by default. If you run WSL2 and depend on vendor kernels or custom kernels, check your WSL kernel release (uname -r inside WSL) and update WSL via the supported methods. Developers using WSL without CAP_NET_ADMIN will have a lower risk profile, but CI agents or containers that run with network admin capability are in scope.
• Azure VMs, AKS nodes, Marketplace images: these must be inventoried. Any VM image that uses a kernel version older than vendor-fixed versions and includes QFQ (built-in or as module) should be updated.
• Edge cases: appliances, custom-built images, or statically linked userland that embed kernel-like components are out of scope for this specific kernel CVE — but the general inventory approach still applies: identify running kernels, verify configuration, patch.

Exploitability and privilege‑escalation profile

• The bug is local and typically requires CAP_NET_ADMIN, which reduces the attack surface against remote unprivileged attackers.
• Vendor statements indicate the vulnerability results in stale read/UAF and does not present a straightforward local privilege‑escalation vector in practice. However, kernel crashes and DoS in multi‑tenant or shared environments (cloud, multiuser servers) are high‑impact.

---

Recommended remediation plan — prioritized checklist​

• Immediate triage (hours)
• Identify all hosts/images in inventory that run Microsoft-supplied Linux artifacts (Azure Linux, Marketplace images, AKS nodes) and WSL deployments.
• Run the discovery commands to detect CONFIG_NET_SCH_QFQ and presence of the sch_qfq module.
• If you find sch_qfq present and you cannot immediately patch, consider short‑term mitigations (module blacklist where feasible and acceptable).
• Patch and update (days)
• Apply vendor kernel updates for Azure Linux and for any distribution images you run. For Azure Linux, use Microsoft’s published package updates or patched images.
• For WSL2, run wsl --update and verify the kernel release inside WSL; if you maintain a custom WSL kernel, rebuild it with the upstream fixes applied.
• For custom or third‑party images, rebuild or repackage with a patched kernel.
• Validation (post‑update)
• After patching, validate the kernel is on a fixed version and that CONFIG_NET_SCH_QFQ is either absent, built with the fixed commits applied, or the sch_qfq module is the fixed package.
• Re-run functional network policy tests for traffic shaping to ensure no regressions.
• Longer‑term hygiene
• Add kernel artifact mapping to your SBOM/VEX/CSAF inventory so future attestations are faster to reconcile.
• Reduce broad use of CAP_NET_ADMIN in user and container runtimes where practical.
• Monitor vendor and upstream kernel advisories for follow‑on fixes or reclassifications.

---

Final assessment and what to tell security leaders​

• Microsoft’s MSRC statement that Azure Linux includes the implicated open‑source library is an authoritative attestation for Azure Linux and should be acted on accordingly by customers using these images.
• The statement does not mean Azure Linux is the only Microsoft product capable of containing the vulnerable sch_qfq code. Microsoft has multiple places where it publishes or ships kernels (WSL2 kernels, Azure VM images, AKS nodes, Marketplace appliances) and those artifacts must be verified individually.
• Operational takeaways for defenders:
• Treat Azure Linux as confirmed and patch it immediately per Microsoft guidance.
• Treat other Microsoft-supplied Linux artifacts as unverified rather than safe until either Microsoft publishes a CSAF/VEX entry mapping them or you confirm via inventory and kernel inspection.
• Prioritize patching hosts that are multi‑tenant, exposed to untrusted users, or provide shared services (CI runners, developer workstations with elevated capabilities).
• The upshot: Microsoft’s wording is transparent and conservative — it tells you what they have checked and promises to expand attestations. It is designed to support machine‑readable automation and is useful — but operational teams must not infer that the absence of an attestation equals absence of risk.

---

Quick mitigation runbook (copy/paste friendly)​

• Identify:
• uname -r
• zcat /proc/config.gz | grep CONFIG_NET_SCH_QFQ || grep CONFIG_NET_SCH_QFQ /boot/config-$(uname -r)
• ls /lib/modules/$(uname -r)/kernel/net/sched | grep qfq
• modinfo sch_qfq || true
• If QFQ component present and you need immediate mitigation:
• Create /etc/modprobe.d/blacklist-sch_qfq.conf containing:
• blacklist sch_qfq
• Regenerate initramfs if your distro requires it (example for Debian/Ubuntu):
• sudo update-initramfs -u
• Reboot or rmmod sch_qfq (rmmod will fail if the qdisc is in use).
• Patch:
• Apply the vendor kernel update (apt/yum/zypper/etc. that contains the backport for CVE-2025-38477.
• For WSL: wsl --update (or confirm Windows Update has applied the WSL kernel update).
• Verify:
• Re-run discovery checks; ensure CONFIG_NET_SCH_QFQ is either absent or the kernel build string corresponds to a vendor-fixed package.

---

Conclusion​

CVE‑2025‑38477 is a real kernel concurrency bug affecting the net/sched sch_qfq code path. Microsoft has publicly attested that Azure Linux includes the implicated upstream component and therefore requires remediation; that attestation is a useful and authoritative signal for Azure Linux customers. However, it is not a blanket denial that other Microsoft products (notably WSL kernels, Azure Marketplace and VM images, AKS node images) cannot include the same vulnerable code. The correct operational approach is straightforward: inventory your Microsoft‑supplied Linux artifacts, verify whether sch_qfq is present on each affected host or image, and patch kernels with vendor‑supplied updates or apply safe mitigations (module blacklist) until fixes are in place. Prioritize multi‑tenant and infrastructure hosts and reduce unnecessary CAP_NET_ADMIN privileges to shrink exposure while you apply updates.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center