CVE-2024-50189: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
Using the device-managed version allows to simplify clean-up in probe()
error path.
Additionally, this device-managed ensures proper cleanup, which helps to
resolve memory errors, page faults, btrfs going read-only, and btrfs
disk corruption.
Security readout for executives and security teams
Plain-English summary
A Linux AMD Sensor Fusion Hub driver cleanup flaw can leave memory improperly managed when device initialization fails. Reported consequences include memory errors, page faults, Btrfs becoming read-only, and disk corruption. This can threaten system availability and data integrity, but the supplied sources do not establish widespread exposure or exploitation.
Executive priority
Treat this as a high-priority reliability and data-integrity issue on potentially affected AMD Linux endpoints, especially Btrfs systems. Accelerate inventory and vendor-kernel updates where driver use or related errors are confirmed. It does not currently justify an emergency response based on exploitation evidence alone.
Technical view
The amd_sfh HID driver used non-device-managed coherent memory allocation, creating improper cleanup in the probe error path. Linux resolved this by switching to dmam_alloc_coherent(), which ties cleanup to the device lifecycle. CVSS 3.1 is 7.8 with local access and low privileges required; confidentiality, integrity, and availability impacts are rated high.
Likely exposure
Exposure is most plausible on Linux systems using the AMD SFH driver where device probing can enter the affected error path. The bundle flags versions 5.11, 5.15.168, 6.1.113, 6.6.57, 6.11.4, and 6.12, but its flattened version data is ambiguous; distribution backports require vendor-specific verification.
Exploitation context
The supplied record is not in KEV, and no cited source reports active exploitation. The CVSS vector describes a local, low-privileged attack context with no user interaction. However, the sources do not explain a reliable attacker-controlled trigger, so intentional exploitation and practical reach remain unconfirmed.
Researcher notes
The source describes a probe-error cleanup defect corrected through device-managed coherent allocation. It does not identify a CWE, demonstrate attacker influence over the failing path, or document proof-of-concept exploitation. Commit-level analysis and distribution patch mapping are needed because the supplied affected-version representation lacks clear range semantics.
Mitigation direction
Install a vendor-supported kernel containing the applicable amd_sfh fix or distribution backport.
Check Linux distribution security guidance to map packaged kernels to the listed upstream fix commits.
Prioritize systems showing AMD SFH initialization failures, page faults, or unexpected Btrfs read-only transitions.
Back up important data before remediation where filesystem corruption indicators are present.
Validation and detection
Inventory kernel versions and determine whether AMD SFH support is present and active.
Compare the running distribution kernel against vendor advisories and backported fix records.
Review system logs for amd_sfh probe failures, memory errors, page faults, and Btrfs warnings.
After updating, confirm the fixed kernel is running and monitor for recurrence of storage errors.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-50189 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.