CVE-2024-47666

What it actually does

Use-after-free in pm8001_phy_control() where a stack address stored in phy->enable_completion is passed to complete() after the function has returned and the stack frame is invalid.

Why it matters to the business

Systems using affected pm80xx SCSI HBAs can experience sudden kernel crashes during PHY reset operations, causing unplanned downtime and potential data loss for storage workloads.

How an attack unfolds

An attacker with local access triggers repeated or timed PHY_LINK_RESET / PHY_HARD_RESET operations so that the firmware response arrives after the 300 ms timeout; the resulting complete() call on the freed stack pointer crashes the kernel.

How to fix it

Update the Linux kernel to a version containing commit ddc501f4130f4baa787cb6cfa309af697179f475 which ensures enable_completion is only set when the caller actually waits for the response.

How to confirm the fix worked

Verify the running kernel contains commit ddc501f4130f4baa787cb6cfa309af697179f475 or later; reproduce PHY reset operations and confirm no crash occurs on late responses.

Typical attack path

1. Obtain local access on a Linux system with pm80xx hardware
2. Issue PHY control ioctls or trigger link reset events via storage management tools
3. Time or repeat operations to produce a late firmware response
4. Trigger the dangling complete() call to cause kernel panic

How to detect it

Search kernel logs and crash dumps for oops or panic messages referencing pm8001_phy_control, enable_completion, or complete() calls originating from the pm80xx driver after a PHY reset timeout.

• pm8001_phy_control
• enable_completion
• PHY_LINK_RESET
• PHY_HARD_RESET

What your security team should do

• Apply the fixed kernel commit immediately on all systems using pm80xx controllers
• Prioritize patching servers that perform frequent link resets or run storage-intensive workloads
• Monitor vendor kernel updates for backports to supported distributions