CVE-2023-53308

What it actually does

In the Linux kernel FEC driver, pm_runtime_resume_and_get() failure in the remove callback returns an error that the driver core ignores, allowing devm-managed resources such as register mappings to be freed while callbacks may still execute, resulting in use-after-free and potential kernel crash.

Why it matters to the business

Linux systems using the affected FEC driver may experience kernel crashes or instability during device removal or power management events, causing operational downtime for network-dependent workloads; the bug affects the widely deployed Linux kernel.

How an attack unfolds

An attacker with local privileges triggers device removal or a failing pm_runtime condition in the FEC driver; the ignored error permits continued removal and freeing of resources, after which a subsequent callback dereferences the freed mapping to induce a crash or potentially escalate privileges.

How to fix it

Upgrade the Linux kernel to version 4.14.316 or later, or apply the fix from commit d52a0cca591e899d4e5c8ab19e067b4c6b7d104f in the stable repository; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel version is at least 4.14.316 or contains commit d52a0cca591e899d4e5c8ab19e067b4c6b7d104f; inspect dmesg or kernel logs after simulated device removal for absence of use-after-free warnings in the FEC driver.

Typical attack path

1. Obtain local access to a system using the FEC driver
2. Trigger device removal or power management failure causing pm_runtime_get to return an error
3. Driver returns error from remove while driver core continues teardown
4. devm resources are released while driver callbacks remain active
5. Later callback accesses freed register mapping causing use-after-free and crash or code execution

How to detect it

Review kernel logs and crash dumps for oops or panic messages referencing the FEC driver during remove or pm_runtime operations; correlate with device hotplug or suspend/resume events.

What your security team should do

• Prioritize kernel upgrade to a fixed version within standard patch cycles given low EPSS and no KEV listing
• Monitor kernel oops and crash reports for FEC-related use-after-free signatures
• Test power-management and hotplug scenarios on FEC-equipped systems before broad deployment