CVE-2024-40944

What it actually does

The vulnerability causes a kernel fault and system crash during kexec if call depth tracking is active, because load_segments() resets the GS segment (setting GS_BASE to 0) before cc_platform_has() is called, which depends on valid per-CPU variables.

Why it matters to the business

Unexpected system crashes and downtime during kernel handoff operations can disrupt services and availability, with repeated occurrences possible in environments using call depth tracking.

How an attack unfolds

An attacker with the ability to trigger kexec operations on a system with call depth tracking enabled causes the GS reset to occur before the platform check, leading to a fault and crash; no widespread threat actor activity is associated.

How to fix it

Update to a fixed kernel version that invokes cc_platform_has() prior to load_segments(); for the listed SuiteCRM GIT package apply commit 504d6f0ebd5847169d73c52d312e91916a7280bb.

How to confirm the fix worked

Inspect the kexec code path to confirm cc_platform_has() executes while GS remains valid, and test kexec operations under active call depth tracking to verify absence of faults.

Typical attack path

1. Gain local access or ability to initiate kexec
2. Ensure or activate call depth tracking
3. Invoke the kexec path that calls load_segments()
4. Trigger the subsequent cc_platform_has() call after GS invalidation
5. Induce kernel fault and system crash

How to detect it

Review kernel panic and oops logs for entries mentioning GS segment reset, invalid GS_BASE, or per-CPU variable access failures around kexec events.

What your security team should do

• Apply the corrected kernel or package version immediately on affected systems
• Test kexec functionality in staging environments after updates
• Monitor kernel logs for GS or per-CPU related faults during maintenance windows