CVE-2024-35800

What it actually does

NULL pointer dereference in EFI get_next_variable() when the pointer is unset (as occurs in kdump kernels), causing kernel panic on boot.

Why it matters to the business

Crash during kexec-based kernel dumps prevents collection of diagnostic data after system failures, lengthening recovery and complicating root-cause analysis on Linux systems.

How an attack unfolds

An attacker with local access triggers a kexec into a kdump kernel; the EFI code path dereferences the unset get_next_variable pointer and panics the kernel, resulting in denial of service.

How to fix it

Upgrade the Linux kernel to version 6.1.84 or later, or apply the commit b9d103aca85f082a343b222493f3cab1219aaaf4. For Debian 11-14 systems also update audiofile to 0.2.6-7.1.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or is at least version 6.1.84; attempt a kexec into a kdump kernel and verify no panic occurs during EFI variable enumeration.

Typical attack path

1. Obtain local execution on a Linux system with EFI and kdump configured
2. Trigger kexec into the capture kernel
3. EFI variable code calls the NULL get_next_variable pointer
4. Kernel panics, halting the kdump process

How to detect it

Search kernel logs for oops or panic messages referencing efi and get_next_variable during kexec or kdump boot sequences; inspect dmesg and /var/log/kern.log around the time of kexec attempts.

What your security team should do

• Prioritize patching production kernels that support kdump within the next maintenance window
• Verify EFI variable handling in test kdump boots after upgrade
• Monitor for kernel oops related to efi during kexec operations