Linux Kernel CVE-2025-38421

Exploitation requires local code execution on an AMD platform whose kernel loads the amd-pmf (Platform Management Framework) driver, and specifically depends on the Smart PC setup path failing so that dev->buf is freed without being nulled; the second free then occurs on the amd-pmf remove/unload path (amd_pmf_remove()). Limiting factors: the attack vector is local (AV:L) and requires low privileges (PR:L), the double free only manifests on the Smart PC initialization failure branch followed by a driver unload event rather than in normal default operation, and only AMD systems with amd-pmf present are affected - non-AMD hosts and systems without the driver loaded are not exposed.

CVSS 3.1 base is 7.8 (High) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - local attack vector, low complexity, low privileges, no user interaction, high impact to confidentiality, integrity and availability. However, these high impact ratings are the theoretical ceiling for a kernel heap double-free; the realistic and most reliable outcome is a kernel crash (denial of service), since the bug only triggers on the Smart PC setup failure path plus a subsequent driver unload, which is not attacker-controlled in default operation. EPSS is very low at 0.15% (5th percentile) and there is no KEV listing and no public exploit identified, all of which agree that mass or opportunistic exploitation is unlikely. The vendor-supplied 'Information Disclosure' tag conflicts with the actual defect class: this is a double-free/memory-corruption issue, not a straightforward info-leak - treat the tag as unreliable. Net assessment: a real but low-priority bug for most fleets, meaningful mainly on AMD endpoints where an attacker already has local low-privileged code execution and can influence driver load/unload.

An attacker with local low-privileged access to an AMD-based Linux machine induces or waits for the amd-pmf Smart PC setup to fail, leaving dev->buf dangling, then triggers an amd-pmf module unload/reload so the stale pointer is freed a second time, corrupting kernel heap state. The most reliable result is a kernel panic (denial of service); with significant additional heap-grooming effort, memory corruption could theoretically be steered toward privilege escalation. No public proof-of-concept has been identified at time of analysis.