Microsoft has released a security update for its Azure Linux distribution to fix a kernel memory leak that could degrade system availability over time. The flaw, tracked as CVE-2024-44971, resides in the Broadcom Starfighter 2 (bcm_sf2) DSA driver and affects Azure Linux hosts that use the affected hardware or have the driver loaded.

The update closes a reference-count imbalance in the driver's PHY device registration path—a class of bug that, while not remotely exploitable, can be abused by local attackers or repeated system configuration changes to steadily consume kernel memory and trigger out-of-memory conditions. Microsoft is urging Azure Linux customers to apply the patch during their next maintenance window.

What actually changed in the kernel.

The vulnerability sits inside the bcm_sf2_mdio_register() function of the bcm_sf2 driver, which handles the initialization and discovery of Ethernet PHY devices on Broadcom-based switches. During startup, the driver iterates through device-tree nodes, finding and removing pre-existing PHYs. In the flawed code path, a call to phy_device_free()—or its underlying put_device()—was omitted after retrieving a device reference, causing the kernel to hold onto the reference long after the object was no longer needed. Over time, and especially across repeated driver reloads or hotplug events, the leaked references accumulate, locking kernel memory that cannot be reclaimed.

The upstream Linux kernel fix, now incorporated into Azure Linux, adds the missing phy_device_free() call at the appropriate exit points. The patch is surgical: a single function call that restores proper reference counting without altering any external behavior or API. As a result, it introduces minimal regression risk while eliminating the memory leak entirely.

This kind of reference-count bug is common in kernel drivers that juggle multiple initialization steps with complex error unwinding. The bcm_sf2 driver’s MDIO registration routine had a “success” path that properly cleaned up, but an early exit or error path skipped the decrement. The fix forces consistent cleanup regardless of the code route taken.

What it means for you.

The practical impact depends on whether you run Azure Linux on hardware that includes a Broadcom Starfighter 2 switch chip—or, more realistically, whether your Azure Linux VMs or container hosts load the bcm_sf2 driver at all. Many Azure virtual machines do not expose this hardware, so direct exposure is limited to specific bare-metal or nested virtualization scenarios. However, Microsoft’s advisory treats any Azure Linux instance with the driver present as potentially affected, because a local, unprivileged user could trigger the leak through repeated device-tree operations or driver bind/unbind sequences.

If you are an Azure Linux administrator, here is how the risk breaks down:

  • If you run standard Azure VMs (non-nested, no passthrough hardware): The driver is likely compiled into your kernel but never activated, so the immediate risk is low. However, a patch is still recommended to match the security baseline.
  • If you operate bare-metal Azure instances, network appliances, or nested VMs that pass through network hardware: The driver could be actively used, and local processes might be able to exercise the faulty path. A malicious actor with shell access—or a compromised application—could degrade service availability by forcing repeated PHY registration cycles.
  • If you run test or development environments where kernels are loaded and unloaded frequently: Even accidental triggering can gradually eat memory, causing unexpected OOM kills or performance hiccups during long-running test suites.

The common thread: the vulnerability is local-only. An attacker needs code execution on the host to exploit it. That raises the bar, but doesn’t eliminate the risk—especially in multi-tenant environments, CI/CD pipelines, or any setup where untrusted code runs on the same kernel.

How we got here.

The flaw was discovered by Linux kernel developers during routine code review and reported through the kernel’s security processes. It was assigned CVE-2024-44971 and patched in the upstream stable kernel trees in mid-2024. From there, major Linux distributions (Ubuntu, SUSE, Red Hat, and others) cherry-picked the fix into their kernels. Microsoft, which maintains its own Azure Linux distribution derived from CBL-Mariner, incorporated the patch into its security update pipeline.

Microsoft’s advisory, published through its Security Response Center, confirms that Azure Linux is affected and that the fix is available through normal update channels. The advisory also notes Microsoft’s commitment to transparency via CSAF/VEX, a standard for expressing vulnerability impact in the software supply chain. This means Azure Linux customers can consume vulnerability data in machine-readable formats and integrate it with their own tooling.

The timeline is straightforward:
- Early 2024: Upstream kernel patch authored and reviewed.
- Mid-2024: CVE assigned; patch merged into stable kernel branches.
- Late 2024 / Early 2025: Microsoft validates the fix and releases updated Azure Linux kernel packages.
- Now: Administrators should be applying the update if they haven’t already.

No public reports indicate active exploitation of this specific CVE in the wild. However, the well-understood exploit path and the low complexity of triggering the leak mean that determined attackers could develop a reliable proof-of-concept quickly. Patching now is a proactive measure against future abuse.

What to do now.

The remediation steps are straightforward but demand attention to your specific environment:

  1. Identify affected hosts. List all Azure Linux instances (physical or virtual) in your inventory. Check which kernel version each is running (uname -r). Microsoft’s advisory does not specify a fixed kernel version publicly, but the update is distributed through the standard package manager. On Azure Linux, you can query for available kernel updates with tdnf check-update kernel.

  2. Apply the update. Install the patched kernel via your normal package management workflow:
    bash sudo tdnf update kernel
    After the update, reboot the instance to load the new kernel. For highly available services, perform a rolling update to avoid downtime.

  3. Verify the fix. After reboot, confirm the kernel version has changed. You can also examine the loaded modules (lsmod | grep bcm_sf2) to see if the driver is active. A patched kernel will have the driver either not loaded (on unaffected hardware) or fixed.

  4. Mitigate if you cannot patch immediately.
    - If the bcm_sf2 driver is not essential, blacklist it: create a file in /etc/modprobe.d/ with blacklist bcm_sf2. This prevents the driver from loading on next boot. Note that any network interfaces relying on this chip will be unavailable.
    - Restrict local access: enforce least privilege, monitor for suspicious kernel logs indicating driver reprobing, and limit shell access to trusted users.
    - Avoid driver reload operations: if your automation scripts bind/unbind the driver, temporarily disable those workflows until the patch is applied.

  5. Monitor for memory pressure. Even after patching, set up proactive monitoring of kernel memory usage. Tools like kmemleak (if enabled in your kernel) can catch similar leaks early. Track system-level metrics (slab usage, MemAvailable) over time to spot trends. An uptick in kernel slab allocations without a corresponding workload increase could indicate a new leak or an unpatched instance.

  6. Review your broader kernel update strategy. Kernel memory leaks are persistent across the industry. Treat kernel security updates with the same urgency as application patches. Azure Linux benefits from Microsoft’s direct oversight, so updates typically arrive quickly after upstream fixes. Automate patch deployment where possible, and test updates in a staging environment that mirrors production hardware.

Outlook.

Reference-count bugs in the Linux kernel are not going away. The mix of manual lifecycle management, complex error paths, and the sheer volume of driver code creates a constant background of similar issues. Microsoft’s prompt integration of the bcm_sf2 fix reflects a mature response pipeline, but the company’s advisory also hints at the broader challenge: Azure Linux is just one distribution, and many customers run a heterogeneous mix of Linux VMs. The fix for this CVE is available upstream for all distributions, so administrators managing other Linux systems should verify their own vendor’s status.

Microsoft’s use of CSAF/VEX data is a positive signal for transparency. As the industry moves toward standardized vulnerability reporting, consumers of Azure Linux can automate impact assessments and patch scheduling. This CVE serves as a test case: a relatively obscure driver bug becomes a manageable operational task when disclosure and remediation are clear.

The long-term lesson is one of discipline. Kernel memory leaks, even local-only ones, accumulate risk over time in always-on, high-uptime environments. Patch early, monitor aggressively, and assume that every missing put_device() is a slow-burning fuse.