CVE-2024-53157

What it actually does

The arm_scpi driver fails to validate the DVFS OPP count returned by firmware before passing it to kcalloc, resulting in a NULL pointer dereference and kernel panic when the count is zero.

Why it matters to the business

Affected Linux systems on certain hardware may experience unexpected kernel crashes and reboots during boot, device probing, or reboot tests, causing unplanned downtime and loss of availability.

How an attack unfolds

An attacker or automated process triggers module load or device probe on systems where SCPI firmware returns a zero OPP count; the unvalidated count leads to a NULL dereference inside scpi_dvfs_recalc_rate during clk registration, panicking the kernel. Threat actors in 2024 zero-day campaigns and Linux kernel resource-handling exploits have targeted similar kernel surfaces.

How to fix it

Upgrade the Linux kernel to a version containing commit 12e2c520a0a4202575e4a45ea41f06a8e9aa3417 or later; rebuild and reboot. For stable trees apply the equivalent backport. Disable the clk_scpi driver if hardware does not require it as a temporary mitigation.

How to confirm the fix worked

Confirm the patch is present by checking the scpi_dvfs_recalc_rate function for an explicit count check before allocation; reproduce the zero-count firmware response in a test environment and verify the probe no longer panics.

Typical attack path

1. Attacker gains local execution or the system performs normal boot/device initialization
2. clk_scpi module loads and calls scpi_clocks_probe
3. Firmware returns DVFS OPP count of zero
4. scpi_dvfs_recalc_rate dereferences a NULL pointer obtained from kcalloc(0, ...)
5. Kernel oops followed by panic and system halt

How to detect it

Search kernel logs, dmesg, and systemd journal for oops/panic traces containing scpi_dvfs_recalc_rate, clk_scpi, or the exact NULL dereference at address 0000000000000028; correlate with systemd-udevd process crashes during scpi_clocks_probe.

• scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
• scpi-hwmon: probe of PHYT000D:00 failed with error -110
• Internal error: Oops: 96000004 [#1] SMP
• Kernel panic - not syncing: Fatal exception

What your security team should do

• Immediately identify all systems running vulnerable kernel versions that use arm_scpi or clk_scpi
• Schedule kernel updates to the fixed commit within the next maintenance window
• Add kernel panic and oops monitoring for scpi-related symbols to detect future occurrences
• Review hardware/firmware combinations known to return zero OPP counts and apply firmware updates where available