CVE-2022-48698

What it actually does

Failure to call dput() after debugfs_lookup() in the AMD display driver leaves a dentry reference held, causing a memory leak on each invocation of the affected debugfs path.

Why it matters to the business

Long-running systems with AMD GPUs may experience gradual kernel memory exhaustion when debugfs interfaces for the display driver are exercised, potentially leading to degraded performance or forced reboots in graphics workloads.

How an attack unfolds

An attacker with local access repeatedly triggers code paths that invoke debugfs_lookup() on AMD display debug entries; each call leaks a small amount of kernel memory until the system becomes unstable or crashes.

How to fix it

Update the Linux kernel to a version containing commit 58acd2ebae034db3bacf38708f508fbd12ae2e54 or later; rebuild and reboot with the patched kernel. Where immediate patching is not possible, avoid exposing or using the affected debugfs interfaces.

How to confirm the fix worked

Confirm the running kernel contains commit 58acd2ebae034db3bacf38708f508fbd12ae2e54; inspect the drm/amd/display code for the addition of dput() after debugfs_lookup() calls; monitor kernel memory statistics under load that exercises display debugfs.

Typical attack path

1. Obtain local shell or userland access on a Linux system with an AMD GPU
2. Interact with or enumerate AMD display debugfs entries to invoke the lookup path
3. Repeat the interaction to accumulate leaked dentries over time
4. Monitor for memory pressure or OOM conditions in the kernel

How to detect it

Review kernel memory usage trends and slab allocator statistics for unexpected dentry growth correlated with AMD display activity; examine system logs for repeated debugfs operations on display driver entries; no public exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates on all AMD GPU hosts within standard maintenance windows
• Add the fixed commit ID to internal kernel build and validation pipelines
• Review any custom tooling or monitoring that accesses AMD display debugfs entries
• Track EPSS and KEV updates for this issue even though current exploitability remains low