CVE-2024-56591: Linux Bluetooth UAF Fix and Azure Linux Attestations

A recently published Linux kernel security advisory, tracked as CVE‑2024‑56591, fixes a flaw in the Bluetooth stack that could allow a local actor to trigger a destructive condition during connection teardown; Microsoft’s Security Response Center (MSRC) has attested that Azure Linux images include the upstream component implicated in the advisory, but that attestation is product‑scoped and does not by itself prove other Microsoft products are free from the same vulnerable code.

Background / Overview​

CVE‑2024‑56591 was disclosed as a bug in the Linux kernel’s Bluetooth connection handling (the hci_conn code path). The upstream fix replaces a call to cancel_delayed_work_sync with disable_delayed_work_sync when taking down a connection so that no new delayed work can be re‑scheduled against an object that’s being freed — a classic race / use‑after‑free mitigation. That change was applied in the kernel stable trees and packaged into distribution updates. The vulnerability’s practical characteristics are important to understand: it is a local vulnerability (an attacker needs local access to the host or an account on the machine) and its primary impact is availability (a crash or kernel instability) rather than remote code execution. Most public trackers rate the issue as moderate with a CVSS score reflecting local access and limited confidentiality or integrity impact. Microsoft’s public advisory language for this CVE states that “Azure Linux includes this open‑source library and is therefore potentially affected,” and it emphasizes that Microsoft has begun publishing machine‑readable CSAF/VEX attestations (starting with Azure Linux) and will update CVE mappings if additional Microsoft products are later found to ship the implicated component. That process and product‑scoped attestation are critical to interpreting Microsoft’s statement.

---

What the fix actually changed (technical summary)​

The bug in plain terms​

• The Bluetooth host controller interface (HCI) connection object schedules work items to run later (delayed work).
• During connection teardown the kernel attempted to cancel that delayed work using cancel_delayed_work_sync.
• cancel_delayed_work_sync cancels existing work but does not prevent the work from being re‑queued immediately after cancellation — leaving a race window where the work can be re‑scheduled against an object about to be freed.
• That race can create a use‑after‑free or similar invalid access that causes a kernel crash or corruption.

The secure alternative​

• disable_delayed_work_sync cancels pending work and disables further scheduling of that work queue for the life of the work_struct object, closing the re‑scheduling window.
• The upstream patch simply switches the cancel call to the disable call at the right point in the teardown sequence; this is an example of a small, local change that eliminates the window of re‑submission and stabilizes object lifetime management.

---

Microsoft’s statement and what “Azure Linux includes this open‑source library” means​

Microsoft has been explicit about how it is rolling out machine‑readable vulnerability attestations (CSAF/VEX) and why Azure Linux was selected as the first product to receive attestations. The key points from Microsoft’s transparency blog and related MSRC messaging:

• Microsoft implemented a phased approach to publishing VEX attestations and started with the Azure Linux distribution (their cloud Linux imagery and kernel artifacts).
• When Microsoft’s Security Update Guide (the MSRC advisory) says a product “includes the open‑source library and is therefore potentially affected,” that is an authoritative attestation for that product only — it documents Microsoft’s inventory work for the named artifact. Microsoft also says it will update CVE records if additional Microsoft products are later identified as carriers.

Put simply: Microsoft’s statement establishes a confirmed, machine‑readable exposure for Azure Linux customers — and that is valuable — but it is not a negative proof that other Microsoft products do not include the same vulnerable Linux kernel sources or compiled modules.

---

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

Short answer: No — not necessarily. Microsoft has publicly attested Azure Linux as including the implicated upstream kernel component, but Microsoft also ships multiple Linux artifacts across product lines (kernel packages for Azure images, WSL2 kernels shipped with Windows, linux‑azure packaged kernels used by cloud VM images, Marketplace images and curated container base images). Any artifact that includes a Linux kernel build from an affected upstream version and with the Bluetooth subsystem enabled could be a carrier until proven otherwise. Independent vendor advisories and distribution trackers (Debian, Ubuntu, SUSE, Oracle) corroborate that the flaw is present in upstream kernel versions and that distributions issued fixes in their kernel packages; those same package families — when repackaged by Microsoft into Azure images or shipped as a Microsoft‑built kernel for WSL — can also carry the same code unless explicitly rebuilt with the fix. This is why the product‑scoped VEX attestation is useful but also why artifact‑level verification remains necessary.

---

Concrete examples: where the same kernel code commonly appears in Microsoft artifacts​

• Azure Linux / linux‑azure — Microsoft’s initial VEX/CSAF work began with the Azure Linux distribution lineage and Azure‑tuned kernels; Ubuntu’s security notices explicitly call out linux‑azure kernel package updates for Azure images, demonstrating vendor coordination around cloud kernel variants. If your instance runs a linux‑azure package, treat it as in‑scope.
• Windows Subsystem for Linux (WSL / WSL2) — WSL2 ships a Microsoft‑compiled Linux kernel that Microsoft maintains and updates separately; the kernel sources and releases are openly available in the microsoft/WSL2‑Linux‑Kernel repository and Microsoft distributes kernel updates via Microsoft Update or WSL update channels. Because Microsoft distributes its own kernel binaries for WSL, the WSL kernel is a plausible carrier for any upstream kernel fix that was not yet applied to the WSL build. Customers should verify the WSL kernel version and apply Microsoft’s kernel updates if needed.
• Marketplace VM images and Azure Marketplace publishers — Marketplace images and vendor appliances can include Linux kernels assembled by Microsoft partners or by Microsoft itself; their kernel versions may differ from the kernel used in Azure Linux attestations. Check the image publisher’s advisory or request an SBOM/VEX attestation for a specific image.
• Curated container base images / internal appliance images — If Microsoft or a Microsoft partner publishes container images that include a kernel (or rely on host kernel modules), the risk profile depends on the host kernel version and the container’s included tooling. These artifacts require per‑artifact inspection.

---

How to verify whether your Microsoft‑supplied artifacts are affected — step by step​

Below are practical steps to confirm whether a given artifact in your estate contains vulnerable kernel code and to remediate.

1. Confirm Azure Linux exposures (if you run Azure Linux)​

1. Check the MSRC Security Update Guide and Microsoft’s VEX/CSAF feed (the authoritative product attestation) for the CVE status for Azure Linux. Treat a “Known Affected” VEX entry for Azure Linux as actionable.
2. On the instance, run: uname -r and compare the kernel package version to your distribution’s security advisory; check the linux‑azure package version (Ubuntu) or the distribution kernel package name your image uses.

2. Inventory other Microsoft artifacts you run (WSL, Marketplace images, curated images)​

1. For WSL: inside a WSL shell run uname -r and also check Microsoft’s WSL kernel release notes or GitHub releases to map the WSL kernel tag to the upstream stable version. Use wsl --status and wsl --update to see and apply updates via Microsoft’s update channel.
2. For Azure Marketplace images: determine the image publisher and image SKU, then request the publisher’s SBOM/VEX attestation or check their security advisory for kernel updates. If no attestation exists, treat the image as under investigation until you can confirm the kernel version and configuration.

3. Kernel artifact inspection (artifact‑level verification)​

1. Extract the kernel package or image and search for the source or binary strings that correspond to the patched commit ID if available; distributions often include upstream commit references in changelogs. If you can extract /boot and /lib/modules, confirm module versions and kernel release.
2. If you find the kernel version is older than the fixed upstream point (for CVE‑2024‑56591 many trackers call out fixes landing in the 6.12.x / 6.13‑rc tree and downstream backports), assume the artifact is vulnerable until the vendor confirms a backport or patch.

4. Mitigation and remediation​

• Update the kernel to a vendor‑patched build or apply the vendor advisory’s fixed package and reboot the host. Local kernel fixes require a reboot to load the corrected kernel image. Ubuntu, Debian, SUSE and other vendors have already published fixed kernel packages; consume those updates via normal package management channels or image updates.
• For WSL: run wsl --update (or the documented Microsoft Update flow) to obtain the latest Microsoft WSL kernel if Microsoft has released a patched WSL kernel. Confirm the new kernel version with uname -r inside WSL and re‑start the distribution.
• If you cannot immediately patch (for example, appliance images controlled by a vendor), implement compensating controls: restrict local access, reduce attack surface by disabling unsolicited Bluetooth access/services, and escalate to the vendor for timelines and attestations.

---

Operational guidance and risk calculus​

• Treat Microsoft’s Azure Linux VEX attestation as canonical for Azure Linux — if you run those images, take the published attestation and remediate according to Microsoft’s guidance. Microsoft’s product‑level attestation is authoritative for that product family.
• Do not assume attestation absence means “not affected” — absence of a VEX/CSAF entry for a product is not proof the product does not contain the vulnerable code; it may simply mean Microsoft has not completed inventory and attestation for that product yet. Until a VEX attestation or SBOM proves otherwise, perform artifact‑level verification for any Microsoft‑distributed kernel image you consume.
• Prioritize exposures by blast radius and exploitability — because CVE‑2024‑56591 requires local access and primarily affects availability, prioritize remediation where you expose many users to shared hosts, multi‑tenant environments, or automated onboarding of untrusted images. For single‑user desktops, weigh patch windows against disruption risk but plan to update promptly. Distribution advisories rate the issue as moderate and packages are available from distribution vendors.

---

Strengths and limitations of Microsoft’s VEX/CSAF rollout​

Strengths​

• Machine‑readable attestations enable automation: customers can programmatically triage Microsoft’s curated inventory for a named CVE and quickly determine which Microsoft product artifacts are known affected, fixed, or not affected. This reduces noise and accelerates response. Microsoft explicitly started with Azure Linux to provide a deterministic signal for cloud images.
• Transparency and a process commitment: Microsoft has stated it will update CVE/VEX entries if additional internal inventory identifies affected Microsoft products, which is a positive procedural guarantee for expanding coverage over time.

Limitations / Risks​

• Phased coverage is not exhaustive: initial attestations are product‑scoped. Large vendors with many kernel images, container base layers, and partner‑published artifacts cannot realistically attest every artifact in a single release — inventory work is incremental. Customers must therefore supplement vendor attestations with artifact inspections and SBOM requests.
• Build‑time configuration differences matter: even two kernels built from the same upstream source can differ in enabled drivers and modules. A kernel with Bluetooth disabled will not carry the same risk, while a WSL kernel or linux‑azure build that compiled Bluetooth support in will. Artifact owners need to verify CONFIG options and module lists where practical.
• Vendor coordination matters for backports: many vendors backport upstream fixes into older stable kernels; determining whether a given Microsoft artifact contains the backport requires vendor confirmation or binary source traceability. Microsoft’s VEX entries remove much guesswork for Azure Linux, but other artifacts may remain opaque until inventory work completes.

---

Practical checklist for security and operations teams​

1. Immediately treat Microsoft’s Azure Linux attestation for CVE‑2024‑56591 as actionable if you run Azure Linux images. Plan image updates and reboots per vendor guidance.
2. Inventory Microsoft‑supplied artifacts (WSL kernels, linux‑azure, Marketplace images, curated container images) across your estate. Map each artifact to a kernel version/build and mark any artifacts with kernels older than the fixed upstream commit as requires remediation.
3. For WSL users and fleets: run wsl --update or use Microsoft Update servicing to install patched WSL kernel builds when Microsoft publishes them; verify using uname -r inside WSL.
4. For appliances or vendor images: request SBOM/VEX attestations or open a support ticket for confirmation; if no timely fix is available, implement compensating controls (restrict local access, isolate hosts, apply least privilege).
5. Subscribe to distribution advisories (Ubuntu USNs, Debian security tracker, SUSE advisories) and Microsoft’s Security Update Guide / VEX feed to capture both vendor patches and Microsoft attestation updates.

---

When a claim is unverifiable and how to treat it​

Any statement that a specific Microsoft product other than Azure Linux is affected can only be confirmed by one of the following:

• A Microsoft VEX/CSAF attestation that names that product as “Known Affected”, or
• A vendor advisory or package update for the named product that references a fix for the same upstream commit, or
• Direct artifact inspection that demonstrates the kernel version and the presence (or absence) of the patched code.

Absent one of those three, claims about other Microsoft products being affected are unverifiable and should be treated as potential exposures until you can perform one of the confirmatory actions above. The recommended operational posture is to assume uncertainty and prioritize artifact verification for high‑risk hosts.

---

Conclusion​

CVE‑2024‑56591 is a targeted Linux kernel Bluetooth bug fixed upstream by replacing cancel_delayed_work_sync with disable_delayed_work_sync to prevent resubmission races during object teardown. Microsoft’s public attestation that Azure Linux includes the affected upstream component is authoritative for Azure Linux — it is a reliable, machine‑readable signal that Azure Linux customers must act on. However, that attestation is product‑scoped and does not prove other Microsoft products are unaffected; Microsoft explicitly commits to expanding attestations as their inventory work completes. Operators should therefore combine Microsoft’s VEX/CSAF outputs with artifact‑level inventory and the distribution vendor advisories (Ubuntu, Debian, SUSE, etc. to determine exposure and remediate by applying vendor kernel updates or Microsoft’s WSL updates where applicable. By treating the Microsoft attestation for Azure Linux as a high‑fidelity, product‑specific input — and by simultaneously verifying other Microsoft artifacts in your environment — you can both obey vendor guidance and close the verification gaps that phased attestations leave behind.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center