Microsoft has issued a security advisory for a Linux kernel bug that leaks memory every time a storage controller is unloaded, slowly eating away at system resources until stability crumbles. The vulnerability, tracked as CVE-2024-57872, lives in the UFS (Universal Flash Storage) platform driver and has been confirmed to affect Azure Linux – Microsoft’s own distribution widely deployed in cloud and edge workloads. Patch now, or risk availability failures in the weeks ahead.

The bug: A cleanup callback left hanging

At its core, CVE-2024-57872 is a programming oversight in the Linux kernel’s device removal path. When a system unbinds a UFS host controller – whether during a routine driver reload, a hardware reconfiguration, or an automated lifecycle event – the cleanup function (ufshcd_pltfrm_remove) fails to call the proper SCSI host release helper. Instead of freeing all kernel memory and handing resources back to the system, it leaves a trail of unreachable data structures.

Each remove/bind cycle leaks a small amount of kernel memory. Individually, the leak is tiny. Repeated over days or weeks on a busy system, it adds up. Eventually, the kernel runs low on memory, triggering OOM (Out Of Memory) kills, hung processes, or even a complete kernel panic. That’s the availability risk the advisory warns about: not a dramatic remote exploit, but a slow-bleed corruption of system health that can take down critical workloads.

How CVE-2024-57872 landed on the Microsoft radar

The underlying bug has existed in the upstream Linux kernel for years – potentially as far back as version 3.10 – and was patched in the stable 6.12.5 kernel release early in 2024. Multiple Linux distributors (Debian, SUSE, Amazon Linux) incorporated the fix soon after. Microsoft, which ships Azure Linux as a first-party distribution for cloud environments, had to verify whether its kernel builds included the vulnerable code and, if so, push out an updated package.

In an October 2025 blog post, Microsoft committed to publishing CSAF (Common Security Advisory Framework) and VEX (Vulnerability Exploitability Exchange) data for all open-source components in Azure Linux. This advisory is part of that transparency push. The MSRC page asks rhetorically whether Azure Linux is the only Microsoft product affected, and the answer is clear: yes, because the UFS driver is compiled only into Linux kernels – not Windows, Hyper-V, or any other Microsoft platform component.

Are you exposed? Here’s how to find out

Azure Linux runs on virtual machines, containers, and Azure Kubernetes Service nodes. If you’re a Windows administrator who also manages Linux workloads in Azure, you need to take this advisory seriously. Even if you don’t use UFS storage directly – it’s more common on ARM devices and embedded systems – the kernel may still load the driver automatically if the module is present.

To check a running Azure Linux instance, use these commands:

  • uname -r – note your kernel version. Versions before 6.12.5-* may be vulnerable.
  • zgrep CONFIG_SCSI_UFS /proc/config.gz || grep -i UFS /boot/config-$(uname -r) – confirms whether UFS support is compiled.
  • lsmod | grep ufs – shows if ufshcd or ufs modules are currently loaded.

Microsoft’s advisory also emphasizes artifact-level verification. Cloud images can vary, so do not assume that all Azure Linux SKUs are patched. Check the kernel changelog for your specific image:

rpm -q --changelog kernel | grep -i ufshcd

or for Debian-based flavors:

apt changelog linux-image-$(uname -r) | grep -i 57872

A positive hit should mention the fix commit that ensures scsi_host_dev_release is called during UFS platform removal. If the changelog is silent, treat the kernel as vulnerable.

What to do today: Patch, mitigate, monitor

Microsoft has already updated Azure Linux kernels to include the upstream fix. The definitive remediation is to install the latest kernel package from the official repository and reboot:

sudo tdnf update kernel
sudo reboot

After the reboot, confirm the new kernel is active with uname -r and verify the changelog one more time.

If you cannot restart immediately – perhaps because the VM hosts a production service with strict uptime policies – short-term mitigations can reduce risk:

  • Avoid driver unbind/reload cycles. Do not run scripts that programmatically unbind UFS controllers, unload the ufshcd module, or invoke sysfs operations on /sys/bus/platform/drivers/ufshcd-pltform.
  • Blacklist the module if it’s not needed. On systems that don’t use UFS storage, create /etc/modprobe.d/blacklist-ufs.conf with:
    blacklist ufshcd
    Warning: This prevents the driver from loading at boot but does not remove an already-running vulnerable module. Test thoroughly on non-production instances first.
  • Isolate critical workloads. If you can’t patch a particular node, migrate high-stakes services to patched instances and limit the blast radius.
  • Set up monitoring. Watch kernel memory usage over time (/proc/meminfo or node_exporter metrics). Alert if slab cache or unreclaimable kernel memory grows steadily without corresponding workload increases.

The bigger picture: Transparency as a service

CVE-2024-57872 is, technically, a low-severity vulnerability with a CVSS score of 5.5. It requires local access and repeated triggering to cause harm. But in cloud environments, where hundreds of identical VMs may share the same kernel image, a subtle memory leak can cascade into widespread availability incidents. Microsoft’s decision to publish a separate advisory – despite the fix coming from upstream Linux – signals a maturing security posture for Azure Linux. By proactively notifying customers and providing CSAF data, the company makes it easier for operations teams to inventory, prioritize, and patch.

For Windows professionals who oversee mixed-OS fleets, the takeaway is clear: treat Linux kernel CVEs with the same rigor you apply to Patch Tuesday. Automate kernel updates where possible, validate against vendor changelogs, and never assume a cloud-provider image is immune without checking.

Outlook: Keep an eye on the module list

The upstream fix is simple and surgical – it adds exactly one missing function call in a teardown path. There’s little risk of regressions. Still, the long tail of unpatched kernels in appliances, IoT devices, and third-party Azure Marketplace images will take time to close. Microsoft’s advisory notes that some vendor images may claim “not affected” when, in fact, they are. Treat any Azure Linux instance with UFS compiled in as suspect until you’ve verified the fix yourself.

Watch for follow-up advisories if Microsoft discovers other products that inadvertently ship the vulnerable library. For now, your job is straightforward: update your Azure Linux kernels, reboot, and verify. The leak stops there.