CVE-2024-26841 in Linux
要約
〜によって VulDB • 2026年05月24日
Linux kernel panic/crash analysis for Loongson-3A6000-HV (LoongArch64)
---
### 1. Summary
- **CPU**: Loongson-3A6000-HV (LoongArch64) - **Kernel**: 6.8.0-rc5+ #1340 (not tainted) - **Process**: `cpuhp/6` (CPU hotplug thread for CPU 6) - **Trigger**: Breakpoint exception (`BRK`) with `ECode=12`, `EsubCode=0` - **Root Cause**: The kernel hit a `break` instruction via `__static_key_slow_dec_cpuslocked()` during CPU deactivation (`sched_cpu_deactivate()`). This is likely an intentional debug breakpoint or a bug in static key handling during CPU hotplug.
---
### 2. Key Registers & Status
- **ECFG**: `00071c1c` → LIE=2-4,10-12, VS=7 (exception configuration) - **ESTAT**: `000c0000` → `[BRK]` (Breakpoint exception)
- **ECode=12, EsubCode=0**: LoongArch-specific breakpoint exception code - **PRID**: `0014d000` → Loongson-64bit, Loongson-3A6000-HV
---
### 3. Call Trace Analysis
``` show_stack+0x48/0x1a0 dump_stack_lvl+0x78/0xa0 __warn+0x90/0x1a0 report_bug+0x1b8/0x280 do_bp+0x264/0x420 ← Breakpoint handler __static_key_slow_dec_cpuslocked+0xec/0x100 ← Static key decrement under CPU lock sched_cpu_deactivate+0x2fc/0x300 ← CPU deactivation path cpuhp_invoke_callback+0x178/0x8a0 ← CPU hotplug callback invocation cpuhp_thread_fun+0xf0/0x240 ← CPU hotplug thread function smpboot_thread_fn+0x1dc/0x2e0 ← SMP boot thread kthread+0x140/0x160 ret_from_kernel_thread+0xc/0xa4 ```
#### Step-by-Step Breakdown:
1. **`cpuhp/6`**: The CPU hotplug thread for CPU 6 is executing. 2. **`cpuhp_thread_fun` → `smpboot_thread_fn`**: Standard CPU hotplug thread entry. 3. **`cpuhp_invoke_callback`**: Invokes the callback for CPU deactivation. 4. **`sched_cpu_deactivate`**: Scheduling subsystem deactivates the CPU. 5. **`__static_key_slow_dec_cpuslocked`**: Decrements a static key while holding the CPU hotplug lock. 6. **`do_bp`**: A breakpoint exception is triggered. 7. **`report_bug` → `__warn` → `dump_stack_lvl` → `show_stack`**: Kernel reports the bug and dumps the stack.
---
### 4. Root Cause Analysis
#### What is a Static Key? Static keys (jump labels) are a kernel optimization mechanism that allows conditional branches to be patched at runtime. They are used in performance-critical paths.
#### Why the Breakpoint? The `__static_key_slow_dec_cpuslocked()` function is part of the static key infrastructure. In some kernel configurations, especially with debugging enabled (`CONFIG_DEBUG_STATIC_KEYS`), a `break` instruction is inserted to catch incorrect usage of static keys.
Possible reasons for the breakpoint: 1. **Incorrect Static Key Usage**: The static key is being decremented while the CPU hotplug lock is held, which may violate locking rules or cause race conditions. 2. **Debugging Flag**: The kernel was built with `CONFIG_DEBUG_STATIC_KEYS=y`, which inserts breakpoints to catch misuse. 3. **Bug in Static Key Code**: A bug in `__static_key_slow_dec_cpuslocked()` or its caller.
#### Why During CPU Deactivation? During CPU deactivation, the kernel may need to update static keys to reflect the new CPU topology. If the static key state is inconsistent or if the decrement is called in an invalid context, the debug breakpoint is triggered.
---
### 5. Recommendations
#### Immediate Actions: 1. **Check Kernel Config**: - Verify if `CONFIG_DEBUG_STATIC_KEYS=y` is enabled. If so
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.