CVE-2024-35947

What it actually does

The vulnerability is an old BUG_ON assertion in the dynamic debug (>control) parser that can be triggered by crafted input, causing an immediate kernel panic instead of graceful error handling.

Why it matters to the business

Systems using dynamic debug features risk unexpected kernel crashes leading to downtime, loss of availability, and potential data corruption in production Linux environments.

How an attack unfolds

An attacker with write access to the dynamic debug control interface supplies malformed input that hits the legacy BUG_ON path; the kernel panics rather than returning an error, achieving denial of service. No named threat actors are known to exploit this specific issue.

How to fix it

Upgrade the Linux kernel to a version containing commit 3c718bddddca9cbef177ac475b94c5c91147fb38 or later; the patch replaces the BUG_ON with pr_err and -EINVAL return.

How to confirm the fix worked

Verify the running kernel contains commit 3c718bddddca9cbef177ac475b94c5c91147fb38; attempt to write the previously crashing input to the control file and confirm the system returns -EINVAL without panicking.

Typical attack path

1. Obtain local access or sufficient privileges to write to /sys/kernel/debug/dynamic_debug/control
2. Craft input that triggers the legacy parser path containing the BUG_ON
3. Write the malicious string to the control file
4. Kernel executes BUG_ON and panics, causing immediate system crash

How to detect it

Review kernel logs for BUG_ON or panic entries mentioning dyndbg or dynamic_debug control parser; correlate with processes writing to the dynamic debug control file around the time of any crash.

What your security team should do

• Prioritize kernel upgrades on all systems exposing dynamic debug interfaces
• Restrict write access to /sys/kernel/debug/dynamic_debug/control to trusted processes only
• Monitor for kernel oops/panic events referencing dyndbg or dynamic_debug
• Test the fix in staging environments before broad deployment