CVE-2024-35983

What it actually does

bits_per() macro incorrectly rounds up when CONFIG_NR_CPUS is a power of two, causing out-of-bounds accesses or invalid bit operations in the bounds checking code and resulting in kernel crashes.

Why it matters to the business

Systems configured with a power-of-two number of CPUs may experience unexpected kernel panics and reboots, leading to unplanned downtime on affected Linux deployments.

How an attack unfolds

An attacker with local access on a vulnerable kernel with power-of-two CONFIG_NR_CPUS triggers the faulty bounds calculation during normal operation or via crafted inputs that exercise the bits_per() path, causing the kernel to crash.

How to fix it

Update the Linux kernel to the fixed commit e8f897f4afef0031fe618a8e94127a0934896aba or later; rebuild and deploy the corrected kernel image on affected systems.

How to confirm the fix worked

Verify the running kernel contains commit e8f897f4afef0031fe618a8e94127a0934896aba or confirm CONFIG_NR_CPUS handling uses the corrected bits_per() logic via source inspection or kernel version checks.

Typical attack path

1. Obtain local shell or userland execution on target system
2. Trigger code paths that invoke bits_per() with a power-of-two CPU count value
3. Kernel performs incorrect bit-width calculation leading to invalid memory access or assertion failure
4. System panics and reboots

How to detect it

Review kernel logs for oops, panic, or bounds-related crash signatures on systems that may have power-of-two CPU counts; no public exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates on systems where CONFIG_NR_CPUS is a power of two
• Test the fixed kernel in staging environments before broad rollout
• Monitor for kernel oops or panic reports matching bounds-related crashes