CVE-2022-48973

What it actually does

The vulnerability is a PCI device reference count leak in the amd8111 GPIO driver; for_each_pci_dev() implemented via pci_get_device() increments the refcount on the returned device, but early loop exit without a matching pci_dev_put() after the 'out' label (and missing cleanup in amd_gpio_exit()) leaves the reference held.

Why it matters to the business

On systems using the affected AMD8111 hardware, repeated driver initialization can gradually exhaust kernel memory or PCI device tracking resources, raising the risk of instability or degraded performance during long-running operations or frequent module load/unload cycles.

How an attack unfolds

An attacker with the ability to trigger repeated initialization of the amd_gpio driver (for example via module reload or hardware enumeration paths) can cause the reference count leak to accumulate; the listed threat actor campaigns and Linux kernel resource issues indicate possible interest by espionage and financially motivated groups in similar kernel flaws, though no public exploit for this specific leak is known.

How to fix it

Update the Linux kernel to a version containing commit 4749c5cc147c9860b96db1e71cc36d1de1bd3f59 (or the equivalent 8dbd7cad914a8b939451c652bfb716aa796f754e in the lif-auth-server tree) which adds the missing pci_dev_put() calls both after the 'out' label and inside amd_gpio_exit().

How to confirm the fix worked

Verify the presence of pci_dev_put() after the loop exit label and in the exit routine of amd_gpio.c; confirm the running kernel contains the listed commit hashes or is newer than the publication date of the fix.

Typical attack path

1. Gain local access or ability to trigger driver initialization on a system with AMD8111 GPIO hardware
2. Cause repeated entry into the for_each_pci_dev loop that exits early without pci_dev_put
3. Accumulate leaked references until resource pressure manifests as instability or denial of service

How to detect it

Examine kernel logs and dmesg for repeated amd_gpio or pci_get_device activity around driver load; correlate with rising PCI device reference counts or memory pressure in /proc/meminfo or slabinfo; review audit logs for unusual module reload patterns.

What your security team should do

• Prioritize patching affected kernels to the listed fixed commits, especially on systems exposing AMD8111 GPIO
• Review kernel update policies to ensure timely ingestion of stable-tree fixes for reference-counting issues
• Monitor EPSS and KEV status for any future elevation in exploitability