CVE-2023-52608

What it actually does

Race condition in the A2P channel ISR of the arm_scmi driver allows a spurious completion IRQ from a late reply to be incorrectly associated with a newly enqueued transaction because the channel free bit is not validated before payload fetch and in-flight lookup.

Why it matters to the business

On ARM platforms using SCMI firmware, this can cause kernel hangs, failed device management commands, or corrupted firmware interactions, potentially leading to system instability or reduced availability in servers, embedded devices, and cloud instances relying on the affected kernel versions.

How an attack unfolds

An attacker with the ability to influence SCMI command timing (via local access or co-located firmware control) triggers command timeouts, waits for platform late replies, then enqueues new requests so the spurious IRQ misassociates the header, bypassing normal transaction validation and allowing the kernel to proceed with stale or attacker-influenced state.

How to fix it

Upgrade the Linux kernel to a version containing commit 614cc65032dcb0b64d23f5c5e338a8a04b12be5d or later; rebuild and deploy the updated kernel across all affected systems; verify the fix is present by checking the arm_scmi driver source for the channel status consistency check in the A2P ISR.

How to confirm the fix worked

Confirm kernel source or binary contains the added consistency check on channel free bit before processing completion IRQ; test by reproducing timeout scenarios and verifying no misassociation occurs; monitor for absence of related kernel warnings or hangs under load.

Typical attack path

1. Gain local execution or firmware co-location on target ARM system
2. Force SCMI command timeouts through resource contention or crafted workloads
3. Trigger platform late reply on the A2P channel
4. Enqueue new SCMI request to overwrite SMT area
5. Allow spurious IRQ to fool in-flight lookup and proceed with mismatched transaction

How to detect it

Search kernel logs and dmesg for arm_scmi or SCMI channel warnings, timeout messages, or IRQ handling anomalies; inspect SCMI mailbox/SMT usage patterns under high load for signs of repeated late replies; review system call traces involving firmware commands for unexpected hangs.

What your security team should do

• Prioritize kernel updates on all ARM systems using SCMI firmware due to potential stability impact
• Apply the fix from commit 614cc65032dcb0b64d23f5c5e338a8a04b12be5d immediately on production workloads
• Review SCMI-dependent device configurations for timeout sensitivity
• Monitor kernel logs for SCMI channel-related anomalies during rollout