CVE-2026-46250: MIPS Linux Kernel Boot Failure – LLVM Compiler Bug

Technical summary

The vulnerability is rooted in a semantic disagreement between GCC and LLVM regarding global register variables. In the Linux kernel, `__current_thread_info` is defined as a global register variable assigned to `$gp` on MIPS. During kernel relocation in `relocate_kernel()`, the code intentionally clobbers `$gp` by assigning it a new address pointing to the relocated kernel. GCC respects this: per its documentation, a callee-saved register used as a global register variable should not be automatically restored if the code clobbers it. LLVM, however, does not follow this behavior and automatically restores `$gp` in the function epilog, regardless of whether it was intentionally modified. This causes `$gp` to retain its pre-relocation value. Subsequently, when `init_idle` executes and attempts to dereference memory through the stale `$gp`, a page fault occurs at address 0x0000000000000000, with the instruction pointer at `ffffffff81afada8` in the `init_idle+0x130/0x270` function. The crash manifests as 'CPU Unable to handle kernel paging request.'

Business impact

Systems relying on MIPS-based Linux deployments compiled with LLVM 18–21 will experience kernel panic during boot, rendering machines entirely non-functional. This affects data center environments, embedded systems, and specialized computing platforms using MIPS processors (such as Loongson systems). Organizations cannot boot affected systems, preventing normal operations, access to data, or service delivery. The impact is equivalent to a complete denial of service at the firmware/kernel level, with no workaround possible without recompilation or kernel updates.

Affected systems

The Linux kernel on MIPS architectures is affected when compiled with LLVM versions 18 through 21. This includes Loongson-based systems (such as Loongson 3 variants) and other MIPS processors. Systems compiled with GCC are unaffected. x86, ARM, and other non-MIPS architectures are not impacted. The vulnerability only manifests at boot time, so only systems undergoing initialization (new deployments, reboots, or updates) experience the failure.

Exploitability

This is a compiler-induced kernel bug rather than a traditional exploitable vulnerability. There is no remote attack vector; the issue triggers automatically during kernel boot on affected systems. An attacker cannot trigger this remotely or from userspace. However, anyone with the ability to rebuild or recompile the kernel using LLVM 18–21 on MIPS will inevitably produce broken binaries. The severity arises from its guaranteed triggering during initialization, not from attacker-controlled exploit conditions.

Remediation

Organizations have two primary paths: (1) Recompile the Linux kernel using GCC instead of LLVM, or (2) if LLVM must be used, wait for LLVM versions 22+ or a backported fix. The Linux kernel community has resolved this by using inline assembly to explicitly assign `$gp` in a way that prevents LLVM from restoring it, effectively working around the compiler bug. Systems already running stable kernels compiled with unaffected toolchains need no action.

Patch guidance

Apply Linux kernel updates that include the workaround commit addressing this issue. The fix uses inline assembly to reassign `$gp` in a manner that LLVM cannot optimize away or restore. Verify your kernel build against the vendor advisory to confirm the patch is included. For MIPS systems currently unable to boot, either: (a) recompile the kernel with an unaffected compiler version, or (b) boot with an older kernel build until patched versions are available. Users should check their distribution's kernel release notes to confirm the fix is integrated.

Detection guidance

Monitor kernel boot logs for the specific panic pattern: 'CPU Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8' occurring during `init_idle` or early scheduler initialization. Check the kernel build environment to identify whether LLVM 18–21 was used. Inspect kernel image metadata or build logs to determine compiler version. Systems that fail to boot immediately after a kernel update or compilation should be cross-checked against their toolchain version. Continuous integration pipelines should validate MIPS kernel builds using only GCC or patched LLVM versions.

Why prioritize this

Although this is not a traditional remote or privilege-escalation vulnerability, it deserves high priority because it causes complete system unavailability on affected deployments. Any MIPS-based system compiled with LLVM 18–21 cannot boot at all. For organizations running Loongson or other MIPS infrastructure, this is a critical operational blocker. The CVSS 7.3 (HIGH) score reflects the impact (availability and integrity loss) and the certainty of exploitation (guaranteed at boot), though it is not remotely exploitable. Priority should be elevated if your environment uses MIPS processors; it can be deprioritized if your infrastructure is exclusively x86 or ARM-based.

Risk score, explained

The CVSS 7.3 score reflects: Attack Vector Local (AV:L)—the vulnerability only manifests during local kernel initialization, not remotely; Attack Complexity Low (AC:L)—any boot attempt triggers it; Privileges Required None (PR:N)—no privilege escalation is needed; User Interaction None (UI:N)—it happens automatically; Scope Unchanged (S:U); Confidentiality Low (C:L) and Integrity Low (I:L)—corrupted memory state leaks some data; Availability High (A:H)—the system is completely unavailable. The high availability impact and guaranteed triggering justify the HIGH severity, despite the local-only attack surface.

Frequently asked questions