CVE-2024-56617

What it actually does

NULL pointer dereference in last_level_cache_is_valid() and update_per_cpu_data_slice_size() during CPU hotplug when cacheinfo was not allocated earlier on architectures such as x86 that skip early build.

Why it matters to the business

Unexpected kernel crashes and system reboots on Linux servers and cloud instances when CPUs are added or removed at runtime, reducing uptime and requiring manual recovery.

How an attack unfolds

An attacker with local privileges triggers a CPU online or offline event on a system where cacheinfo allocation was skipped; the hotplug callback then dereferences a NULL pointer, causing an Oops and kernel panic. No remote vector or privilege escalation is present.

How to fix it

Update to a kernel containing commit 23b5908b11b77ff8d7b8f7b8f11cbab2e1f4bfc2 or later; rebuild and reboot with the fixed kernel. Disable unnecessary CPU hotplug if the update cannot be applied immediately.

How to confirm the fix worked

Verify the running kernel contains commit 23b5908b11b77ff8d7b8f11cbab2e1f4bfc2; attempt CPU online/offline operations in a test environment and confirm no NULL dereference oops occurs.

Typical attack path

1. Obtain local shell or code execution on the target Linux system
2. Trigger CPU hotplug via sysfs or cpufreq interfaces
3. Kernel executes cacheinfo CPU hotplug callback without prior allocation
4. NULL dereference occurs leading to panic

How to detect it

Search kernel logs for BUG: kernel NULL pointer dereference messages referencing last_level_cache_is_valid and cpuhp threads; examine dmesg output around CPU hotplug events.

• last_level_cache_is_valid+0x95/0xe0
• BUG: kernel NULL pointer dereference, address: 0000000000000100
• CPU: .* PID .* Comm: cpuhp/

What your security team should do

• Apply the fixed kernel version immediately on all production Linux systems
• Prioritize systems that perform frequent CPU hotplug such as virtualization hosts
• Monitor kernel logs for cacheinfo-related oops until patching is complete