CVE-2024-44995: HNS3 Deadlock and Azure Linux Attestation

Microsoft’s short, one‑line attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a product‑scoped inventory statement, not a universal guarantee that no other Microsoft product contains the same vulnerable Linux kernel code.

---

Background / Overview​

CVE‑2024‑44995 is a Linux‑kernel bug in the HiSilicon HNS3 network driver (the net: hns3 tree). The defect is a concurrency/improper‑locking issue that can produce a deadlock when Traffic Control (TC) configuration occurs while the driver or port is being reset. The upstream Linux maintainers accepted a small, surgical change to ensure the driver takes the port DOWN at the correct point during the UINIT/reset flow, eliminating the race that could otherwise leave callers waiting indefinitely.
This vulnerability is tracked as CVE‑2024‑44995 in public CVE/OSV/NVD databases and was published in early September 2024; distribution vendors and kernel maintainers merged the fix into the relevant stable trees (including 6.10‑stable) and shipped it into downstream distribution kernels. The public advisories consistently describe the issue as an availability risk (deadlock) rather than a confidentiality or integrity breach.
Microsoft’s MSRC listing for CVE entries (and the follow‑on VEX/CSAF machinery) takes an intentionally conservative approach: when Microsoft’s inventory finds an upstream component present in a product family, the MSRC advisory will state that the product “includes this open‑source library and is therefore potentially affected” and will promise to expand that mapping if additional Microsoft products are later found to ship the component. That phrasing is what prompted the original question: does that sentence mean Azure Linux is the only Microsoft product that could be affected? The short operational answer is **no — nrosoft has publicly attested Azure Linux for this and many similar CVEs because that product family was the inventory target for the initial VEX/CSAF rollout; the attestation is authoritative for Azure Linux, but it does not by itself prove exclusivity.

---

What CVE‑2024‑44995 actually is (technical summary)​

The bug in plain engineering terms​

• The HNS3 driver manages network ports with sequences that include DOWN, UINIT (unregister NAPI handler), INIT (register NAPI handler), and UP operations.
• Under certain timings, a concurrent TC (Traffic Control / qdisc / classifier) setup can attempt to bring a port UP before the driver has completed UINIT during a reset.
• That interleaving allows two code paths to hold or expect conflicting locks or NAPI state transitions, producing a deadlock condition that prevents forward progress — effectively an availability loss until manual intervention or a reboot.

Scope and severity​

• The defect is an availability (denial‑of‑service) problem; confidentiality and integrity are not implicated by the published descriptions.
• Public trackers report a CVSSv3 base score of 5.5 (medium) reflecting a local/privileged‑orchestrated availability impact; exploitability generally requires the ability to trigger TC configuration or operations on the affected host.

Where the fix lives​

• The upstream kernel patches were merged into the stable kernel trees (fixes appear in 6.10‑stable and related branches), and kernel vendors produced distribution patches. The kernel patchset is small and focused on adding a DOWN in the UINIT path to force deterministic state before permitting setup TC to UP the port.

---

Why Microsoft named Azure Linux — and what that naming does and does not mean​

What Microsoft actually said​

Microsoft’s public CVE entries (the MSRC update guide pages) and the company’s machine‑readable VEX/CSAF rollout use a consistent phrase: Microsoft has inventory‑checked Azure Linux and found the implicated upstream component present, so it lists Azure Linux as “potentially affected.” Microsoft also announced a phased plan to publish VEX attestations starting with Azure Linux in October 2025, and to expand product mappings when further inventory is completed. That process improves transparency for customers but — again — it begins with a focused product.

Why this is deliberately scoped and cautious​

• Large vendors ship many artifacts: distribution kernels, cloud VM images, container base images, appliance images, WSL kernels, edge device images, SDKs and static binaries.
• Whether a particular upstream file (for example, drivers/net/ethernet/hisilicon/hns3/*.c) appears in any of those artifacts depends on:
• Which kernel snahot the artifact used,
• How the kernel was configured at build time (CONFIG options for specific drivers),
• Whether the driver is built as a module or built‑in,
• Whether the artifact includes the kernel at all (Windows server images vs Linux images), and
• Packaging/backport choices (some teams copy patches into older trees).
• Microsoft’s attestation therefore tells Azure Linux customers a definitive, actionable fact — those images were checked and are in‑scope — without asserting that every other Microsoft artifact has been exhaustively scanned. That conservative phrasing is both accurate and responsible, but it leaves an uncertainty surface for other products until per‑artifact verification is done.

---

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

Short answer​

No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable HNS3 kernel code. It is, however, the only Microsoft product Microsoft has publicly attested to include the component so far. That attestation is operationally useful: if you run Azure Linux images, treat them as in‑scope and apply Microsoft’s updates. For other Microsoft artifacts, you must verify.

Longer answer — how to decide if your Microsoft artifact is affected​

Any Microsoft product that actually ships a Linux kernel image or a kernel module built from a kernel tree that included the HNS3 driver could theoretically carry the vulnerable code. Candidate Microsoft artifacts that you should check include, but are not limited to:

• Azure Linux VM images (confirmed by MSRC as in‑scope).
• Azure Marketplace VM images that embed custom kernels or distro snapshots.
• Azure services that run managed Linux kernels (kernel variants in managed services or host OS images).
• Microsoft‑shipped WSL kernel images (the Windows Subsystem for Linux uses a Microsoft‑provided Linux kernel image on some releases).
• Any Microsoft appliance or partner image that uses Microsoft‑curated Linux kernel builds.
• Internal service artifacts or SDKs that embed or ship kernel modules as part of a device or embedded image.

Whether any of those actually contains HNS3 depends on build choices and kernels used; it is not sufficient to assume absence just because MSRC only listed Azure Linux. You should run artifact‑level checks.

---

Practical verification steps (how to tell if a host or image contains the vulnerable HNS3 code)​

If you manage Linux images or cloud VMs and need to know whether those images include the HNS3 driver (and therefore might be affected before a vendor patch is applied), do the following checks. These are low‑risk, standard diagnostics you can run from a shell:

• Check for a loaded module named hns3:
• sudo lsmod | grep -i hns3
• If the module is present, view details:
• sudo modinfo hns3
• Inspect the kernel config used to build the running kernel:
• zgrep CONFIG_HNS3 /proc/config.gz
• or grep -i hnme -r)
  A value of =y or =m shows whether the driver was built in or as a module.
• Search the kernel image for driver files if you have the kernel source or packages:
• rpm -ql kernel | grep hns3 (on RPM‑based distros)
• apt list --installed | grep linux-image (on Debian/Ubuntu) and inspect corresponding /boot/config-*
• Check boot logs and dmesg for hns3 strings:
• dmesg | grep -i hns3
• For images (WSL or VM images) that you cannot boot directly, request or download the SBOM (software bill of materials) or inspect the image manifest and kernel package versions. Microsoft’s VEX/CSAF materials aim to make these attestations machine‑readable for Azure Linux customers; for other artifacts you may need to request a vendor SBOM or perform offline inspection.

These steps let you confirm the presence and build method for HNS3 without guessing. If HNS3 is absent (module not present and CONFIG_HNS3 unset), the artifact is not affected by this driver bug. If HNS3 is present, you need to know the kernel version and whether vendor kernels have backported the fix.

---

Remediation and mitigation guidance​

Immediate actions (operational checklist)​

• Prioritize Azure Linux hosts: apply the Microsoft package updates for the kernel that include the upstream HNS3 fix and reboot hosts as required. Microsoft’s attestation makes these images definitively in‑scope for remediation.
• For any other Microsoft‑supplied Linux artifact (WSL kernels, Marketplace images, managed services), treat the MSRC attestation as a signal rather than an exhaustive inventory. Perform the artifact checks described above; if HNS3 is present, apply vendor updates or block TC‑reconfiguration activities as a temporary mitigation.
• If you cannot patch immediately, reduce exposure by limiting who can configure TC on affected hosts (restrict the relevant administrative interfaces and automation pipelines), and monitor for symptoms (unexpected network hangs or NAPI state transitions in dmesg). The bug requires TC configuration during reset timing to trigger, so constraining when changes happen reduces the attack surface.
• Use distribution advisories (Debian, Ubuntu, SUSE, Red Hat, etc.) and your internal patch‑management tools to find kernel packages that include the specific stable patch. Upstream patch metadata and distribution advisories have already tracked and rolled fixes into downstream packages.

A recommended patch/validation workflow​

• Inventory your Linux artifacts (images, kernels, running VMs, WSL images).
• For each artifact that contains HNS3, determine kernel version and vendor kernel package release date.
• Cross‑reference vendor advisories or kernel stable commits to identify whether the upstream fix has been backported. Kernel patches are small; vendors often publish CVE mapping or release notes.
• Schedule package updates and reboots in a controlled maintenance window.
• After patching, validate by checking kernel version and dmesg for any remaining hns3 warnings; run a test scenario that exercises TC during a controlled reset to verify the problem no longer reproduces (in staging before production).

---

Detection, telemetry and monitoring suggestions​

• Instrument dmesg/boot logs for NAPI and hns3 messages; unexpected repeated napi_enable()/napi_disable() sequences or netif_napi_add/netif_napi_del errors may indicate a problem.
• Monitor automation and orchestration systems for failed or hung TC operations and for network‑reset events that do not complete.
• If you use host introspection or kernel crash telemetry, add detection rules for hang patterns related to net device reset paths; correlate these with recent TC configuration events.
• Consider scanning deployed images with a tool that understands kernel modules and can detect presence of drivers like HNS3 (SBOM‑aware scanners, package scanners and image content inspection tools can help).

---

Risk analysis: strengths, exposure vectors and mitigations​

Strengths / low‑risk aspects of the bug​

• The vulnerability is localized to a network driver (HNS3), not a generic kernel memory‑corruption primitive; its impact is availability (deadlock) rather than arbitrary code execution or data leak.
• Successful triggering typically requires privileged or semi‑privileged actions (configuring TC), network adapter presence, or specific operational conditions; remote, unauthenticated exploitation is not the primary use case described by public trackers.

Areas of potential concern​

• Cloud and multi‑tenant environments often expose interfaces that allow programmatic network reconfiguration; orchestration systems, container/VM utomated networking stacks might inadvertently trigger the problematic sequence at scale.
• Backports: some vendors backport fixes to older kernel branches while others may not; a machine running an older vendor kernel might remain vulnerable even if newer kernels are patched. Always check vendor advisories.
• Visibility gaps caused by vendor packaging: a product that bundles a kernel snapshot could be vulnerable even if the vendor does not list the CVE until an inventory completes.

Specific Microsoft ecosystem risk notes​

• Azure Linux customers should treat Microsoft’s attestation as a primary operational signal and apply Microsoft’s kernel updates promptly. Microsoft’s transparency program (CSAF/VEX) that began rollout with Azure Linux improves this process by providing machine‑readable attestations; Microsoft has said it will expand product mappings over time.
• Customers running other Microsoft‑supplied images (WSL, Marketplace images, guest images obtained via Microsoft repositories) should not assume they are safe merely because MSRC listed only Azure Linux for this CVE; they should perform artifact verification until Microsoft’s VEX mapping is expanded.

---

Cross‑references and evidence​

• The CVE entry and technical description are visible in public vulnerability databases (NVD/OSV) and describe the HNS3 deadlock and the fix details.
• Kernel maintainers merged the patches into the stable kernel trees (6.10‑stable and related branches) — you can find the upstream commits referenced in the public CVE aggregators and kernel commit logs.
• Microsoft’s MSRC launch and VEX/CSAF rollout (October 2025) and the company’s product‑scoped CVE wording explain why Azure Linux was named and why Microsoft will expand mappings; this is a product‑inventory policy rather than a statement of exclusivity.
• Community advisories and distribution trackers (Tenable, Snyk, AWS/ALAS) have listed the CVE and tied it to distribution packages; these corroborate the upstream description and show how downstream vendors are tracking the fix.
• Our internal file collection and prior coverage explain that Microsoft’s product attestation pattern is consistent across many kernel CVEs: the vendor lists Azure Linux first while promising to update VEX mappings when additional Microsoft products are discovered to ship the component. That pattern is the reason administrators must perform artifact‑level checks for non‑Azure‑Linux images.

---

Practical recommendations for defenders (concise checklist)​

• If you run Azure Linux: prioritize and apply Microsoft kernel updates for CVE‑2024‑44995 immediately and schedule reboots as instructed.
• Inventory other Microsoft artifacts in your environment (WSL kernels, Azure Marketplace images, managed services) and run the detection commands above; where HNS3 is present, plan patching or temporary mitigations.
• Use SBOMs, image scanning, and package inventory tooling to find any copy of the HNS3 driver across builds and images — do not rely solely on vendor CVE mappings until the vendor declares the artifact “Not Affected” or “Fixed” via VEX/CSAF.
• Limit who can perform TC changes on production hosts until you confirm kernel status, and monitor orchestration workflows that may cause automated reconfiguration.
• Coordinate with patch windows and automate the verification of kernel packages after updates (check package hashes and kernel‑release values).

---

Closing analysis — what to expect next and how to interpret vendor language​

Microsoft’s MSRC attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is an operationally correct but intentionally scoped statement: it tells Azure Linux customers what they need to know now, and it documents Microsoft’s intent to expand VEX/CSAF coverage to additional products over time. That process improves transparency, but it does not replace the immediate need for artifact‑level verification across every Microsoft image you run.
For defenders, the right operational stance is clear:

• Treat Microsoft’s attestation as authoritative for Azure Linux and patch accordingly.
• Treat the absence of an MSRC attestation for other Microsoft products as uncertainty, not as proof of safety.
• Use deterministic artifact inspection (SBOMs, kernel configs, modinfo, dmesg) to decide the remediation priority for anything else that Microsoft ships into your environment.

If you want, use the detection commands and the patch/validation workflow above to create a short playbook you can hand to your operations team: it’s the fastest way to convert vendor attestation and upstream patch information into measurable, auditable action that protects availability in your environment.

---

CVE‑2024‑44995 is a concrete, well‑understood kernel driver fix: the vulnerability has been patched upstream, multiple distribution and tracking services list the fix, and Microsoft has taken the sensible step of naming Azure Linux as an affected product while committing to expand VEX-based attestations over time. That combination — upstream fix + vendor attestation + artifact verification — is the right sequence for defenders: patch promptly where attested, verify everywhere else, and monitor for any operational signs of the deadlock until your entire fleet is confirmed fixed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center