Linux UFS Platform Driver Fix CVE-2024-57872: Prevent Memory Leaks

A subtle lifecycle bug in the Linux UFS platform driver — tracked as CVE-2024-57872 — can leave a host bus adapter (HBA) detached code path improperly cleaned up during ufshcd_pltfrm_remove, producing memory leaks and an availability risk for affected systems. The fix upstream ensures the SCSI host is released with scsi_host_dev_release during platform remove, closing the resource-leak window; operators should treat this as an availability-focused kernel patch to apply promptly where the UFS stack is present.

Background / Overview​

UFS (Universal Flash Storage) is a common storage interface on embedded platforms and many ARM-based systems. The kernel implements UFS support through the UFS host controller driver (ufshcd) and platform glue (pltfrm) code that binds hardware resources, registers SCSI hosts, and handles lifecycle events such as probe and remove. When cleanup on remove is incomplete, kernel objects can be leaked or left in inconsistent state; repeated leaks may degrade system stability or, in rare cases, cause crashes or service outages.
CVE-2024-57872 is described succinctly by upstream trackers: during ufshcd_pltfrm_remove, the platform code fails to properly deallocate the HBA and ensure the SCSI host is cleaned up with scsi_host_dev_release, which can leave remnants that lead to memory leaks and availability impacts. This vulnerability has been recorded in public vulnerability databases and assigned a medium operational severity in common triage models.

---

What the vulnerability actually is​

The technical root cause (in plain language)​

• The platform remove path (ufshcd_pltfrm_remove did not guarantee that the SCSI host bound to the UFS controller was released via the kernel helper scsi_host_dev_release.
• As a result, some device- or host-level structures could remain referenced or partially deregistered, producing a memory leak or leaving subsystem state inconsistent during device removal.
• Over time or across repeated removal/rebind cycles, leaking kernel objects can degrade system resources and create availability problems — from hung services to the need for manual intervention or reboot.

Impact profile​

• Primary impact: Availability (resource exhaustion and potential instability). The public CVE descriptions classify the vulnerability as causing memory leaks that could affect service availability.
• Attack vector: Local — an attacker or misbehaving process with the ability to trigger platform device remove/unbind sequences (for example via platform-specific sysfs interfaces or privileged device-control actions) can create the condition. Many real-world exposures arise in embedded devices, vendor images, and systems where local administrative/automation tasks manage driver lifecycle.
• Exploitability: Not a remote RCE — this is a correctness/resource-management bug rather than a memory-corruption primitive enabling code execution. The credible impact is denial-of-service or persistent availability loss, not privilege escalation or data exfiltration. That said, availability failures in multi-tenant or storage-critical systems are high-opportunity incidents and should be prioritized accordingly.

---

Who is affected​

Kernel versions and distribution mapping​

Multiple vulnerability trackers and distro advisories indicate the vulnerability affects a wide range of Linux kernel versions compiled with the UFS/pltfrm code present. Public mappings commonly list kernels starting from older stable branches up to kernels before a 6.12.5 upstream fix (i.e., vulnerable versions are approximately >= 3.10 and < 6.12.5, with certain RC windows noted). Distributions and downstream kernels may vary because of backports and vendor-specific kernels; always verify package changelogs for your exact kernel build.

• Example vendor/distro signals:
• Debian’s tracker shows versions and fixed-package rollups for several releases, and lists the upstream commit reference used to mark the fix in stable kernels. Operators should consult their distribution’s security tracker for exact package names and fixed versions.
• SUSE and Amazon trackers provide their own scoring and package-state notes; SUSE marks their overall state as resolved and lists their internal severity; Amazon’s ALAS page lists platform-specific status and a CVSS v3 score in vendor context. These vendor signals often differ slightly in severity rating but agree on the technical remediation.

Where exposure is most concerning​

• Embedded appliances, mobile/ARM devices, and vendor-kernel images where UFS is compiled in or provided as an out-of-tree module.
• Virtualization hosts or servers that run vendor kernels containing UFS code (less common on x86 desktops but possible in certain appliance images).
• Systems with frequent device remove/rebind cycles or automated module reload activities (CI systems, development labs, serial device test rigs).
• OEM-provisioned images and Marketplace appliance images where the vendor’s update cadence may lag upstream distribution kernels. Microsoft’s guidance emphasizes artifact-level verification for cloud-supplied images because different kernel builds may or may not carry the vulnerable code.

---

Severity, scoring, and practical risk​

Scores reported publicly​

• CVSS v3 base score commonly shown: 5.5 (Medium) in several public trackers and vendor feeds; this reflects a local vector and high availability impact in the scoring model.
• Some vendors (SUSE) calculate different internal scores (SUSE lists a lower availability impact in its own scheme), which demonstrates that scoring can vary by operational lens. Use vendor advisory context to interpret impact for your environment.

What the numeric score means operationally​

• A medium CVSS score with Availability flagged typically indicates a vulnerability that can cause system outages or service degradation when triggered, but does not provide an immediate remote code-execution capability.
• In multi-tenant or storage-critical contexts, even a medium-scored vulnerability can be high-priority for patching because a single local exploit or misconfiguration could affect many services.

Likelihood of exploitation​

• Publicly observed exploit activity or proof-of-concept code has not been reported as a reliable RCE chain for this CVE. The highest-likelihood scenario is a local or privileged actor (or a malicious local process) intentionally triggering remove/unbind flows to cause leaks or repeated failure. Treat remote, unauthenticated exploitation claims as unverified unless a vendor or telemetry report provides proof.

---

Upstream fix and what changed​

• The upstream kernel patch ensures the platform remove path calls the correct SCSI host cleanup helper (scsi_host_dev_release when deallocating the HBA in ufshcd_pltfrm_remove. This guarantees that the SCSI host is properly cleaned and prevents leaked state. Kernel stable trees incorporated the change and maintainers propagated it into stable branches. Operators should look for the upstream commit in kernel changelogs and distribution package notes.

---

Detection and verification — concrete steps​

Administrators should verify whether a host is affected and whether their running kernel includes the fix.

Quick checks (on a running system)​

• Check your running kernel:
• uname -r
• Inspect kernel config: zgrep CONFIG_UFS /proc/config.gz or cat /boot/config-$(uname -r) | grep -i UFS
• Confirm whether UFS modules are present:
• modinfo ufs && modinfo ufshcd
• lsmod | grep ufs
• Search kernel changelogs and package metadata for the CVE or the upstream stable commit ID that fixed ufshcd_pltfrm_remove:
• Debian/Ubuntu: apt changelog linux-image-$(uname -r) | grep -i 57872
• RPM-based: rpm -q --changelog kernel | grep -i ufshcd
• For cloud images or vendor appliances, treat each image as a distinct artifact and verify its kernel package / build metadata before assuming it is safe. Microsoft’s advisory guidance recommends confirming at the artifact level for Azure and Marketplace images.

What to look for in logs​

• Persistent kernel warnings referencing UFS/ufshcd during device remove or bind/unbind cycles.
• Symptoms related to growing kernel memory usage following repeated device plug/unplug or module reload operations.
• If available, collect dmesg / journalctl -k output around device remove sequences to capture any oops, WARN, or refcount messages.

(If you find ambiguous traces or atypical behavior, capture full kernel logs and contact your distribution/vendor support; never assume an absence of messages equals absence of exposure.
Citations for public verification procedures and examples appear in vendor trackers and distribution advisories.

---

Remediation and mitigation​

Definitive remediation​

• Install a kernel package from your vendor or distribution that explicitly includes the upstream fix for CVE-2024-57872 and reboot into the patched kernel. This is the only guaranteed remediation because the bug is in kernel device lifecycle code. Distribution security advisories and changelogs will state the exact fixed package versions.

Short-term mitigations (if you cannot patch immediately)​

• Avoid workflows that perform frequent remove/unbind of UFS controllers or that programmatically cycle modules on production hosts.
• If UFS/ufshcd is not required, consider blacklisting the driver (for example, echo "blacklist ufshcd" > /etc/modprobe.d/ufshcd-blacklist.conf) only after verifying that no critical hardware depends on it. On embedded devices, this may not be a viable option. Blacklisting prevents the module from loading but does not correct already-running kernels.
• For cloud or appliance images where patching is delayed, isolate affected machines from critical workloads and reduce the blast radius of potential availability degradation. Schedule maintenance windows to apply kernel upgrades.
• Use monitoring to detect and alert on repeated device-remove patterns or increasing kernel memory consumption tied to platform drivers.

Recommended rollout strategy​

• Inventory: identify systems with UFS/ufshcd present (module or built-in).
• Prioritize: patch systems that host critical services or multi-tenant workloads first.
• Stage: apply fixed kernels to test/pilot systems and validate storage and device lifecycle behaviors.
• Deploy: roll out across production with monitoring windows to watch for regressions or residual failures.
• Verify: confirm the fixed kernel is active and that prior ufs/ufshcd warnings do not recur.

---

Operational analysis — strengths of the upstream response, and residual risks​

Strengths​

• The upstream change is small and surgical — it restores a missing cleanup call in an error path rather than redesigning large subsystems. This usually makes vendor backports and testing straightforward and low-risk.
• The fix is present in the kernel stable trees and has been tracked by multiple distribution security teams, which eases mapping to vendor package updates.

Residual risks and caveats​

• Vendor and OEM lag: embedded devices and vendor-supplied kernels often receive backports on longer timelines, creating a long tail of exposed devices.
• Artifact variance: cloud marketplaces, OEM images, and custom kernels may compile different CONFIG options; a vendor might claim “not affected” for certain images while others remain vulnerable. Microsoft explicitly warns operators to verify at the artifact level.
• Detection gap: memory leaks can be stealthy; they may not immediately crash a host but can degrade performance or trigger OOM conditions over time. Operators should add lifecycle and memory usage telemetry to catch slow-failure modes.

---

Practical checklist for administrators (actionable)​

• Inventory all kernels and images for UFS/ufshcd presence:
• uname -r; zgrep CONFIG_UFS /proc/config.gz; lsmod | grep ufshcd.
• Cross-reference your kernel package changelogs with vendor advisories for CVE-2024-57872 or the upstream stable commit (the changelog will often include the commit ID).
• Patch high-priority hosts first; reboot into the patched kernel.
• For appliances or vendor kernels with no patch available, contact the vendor for an update plan and apply mitigations (blacklist, isolate) until a fixed image is provided.
• Monitor logs for UFS remove/bind traces and watch kernel memory trends after patching to confirm remediation.

---

Cross-check and corroboration​

This analysis and the recommended actions are corroborated by multiple independent sources: NVD’s CVE record and enrichment notes describe the technical fix and the affected code path; distribution trackers (Debian) and vendor advisories (SUSE, Amazon ALAS) list affected packages and package statuses; security aggregators (Aqua/AquaSec, Enginsight) provide additional contextual scoring and mapping across kernel versions; and cloud-provider guidance encourages artifact-level verification because image builds vary. Those independent sources converge on the technical remediation (call scsi_host_dev_release on remove) and the operational guidance (install patched kernels and validate). Caveat: some distribution-specific severity scores and package states differ slightly; always use your vendor’s advisory and the distribution changelog to determine exact fixed package names and deployment steps for your environment.

---

Conclusion​

CVE-2024-57872 is a classic kernel lifecycle correctness issue: a missing deallocation/cleanup during UFS platform remove resulted in leaked SCSI host state and potential availability consequences. It is not an immediate remote code-execution risk, but it is operationally significant where UFS-based controllers are deployed — especially in embedded platforms, OEM images, and appliances where kernel backport cycles can be slow.
The upstream fix is straightforward, low-risk, and available in kernel stable trees; the operational imperative is to map that upstream commit to your distribution or vendor kernel packages, apply the update, and reboot affected systems. Where patching cannot happen immediately, apply mitigations such as avoiding device remove cycles, blacklisting the driver when feasible, and isolating exposed hosts.
Treat the vulnerability as an availability-first risk: inventory, patch, validate, and monitor to ensure the UFS platform driver is no longer leaving SCSI hosts half-released during device teardown.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center