CVE-2026-46250

What it actually does

This flaw affects Linux kernels for MIPS systems when built with affected LLVM versions, reported as at least LLVM 18 through 21. During early kernel relocation, the MIPS global pointer register ($gp), used for __current_thread_info, can be restored incorrectly by the compiler after being intentionally changed. The kernel then continues execution with $gp pointing at the unrelocated kernel image, which can cause invalid memory references very early in boot, including a kernel paging request fault in init_idle during scheduler initialization. The primary impact is denial of service through failure to boot; confidentiality and integrity impact are limited and are not the main practical concern described by the fix.

Why it matters to the business

Organizations running MIPS-based Linux systems, including embedded, appliance, networking, or specialized hardware platforms, may experience systems that fail to boot after deploying an affected kernel build. This can cause device outages, failed firmware or OS upgrades, rollback events, maintenance windows that overrun, and loss of service availability. The vulnerability is not in CISA KEV, is not associated with ransomware use, has no known public exploit maturity in the provided data, and has a very low EPSS score, so urgency is highest for organizations that build or ship MIPS Linux kernels with LLVM rather than for broad internet-exposed exploitation risk.

How an attack unfolds

A practical exploitation scenario requires the target to run or boot a vulnerable MIPS Linux kernel image that was built with an affected LLVM compiler. An attacker would need a way to influence kernel deployment, kernel build settings, firmware images, boot media, or a local boot/update path so that the affected kernel is installed and selected at boot. When the system starts, the kernel relocation routine executes, LLVM-generated code restores $gp contrary to the expectation for the global register variable, and later early boot code uses the stale pointer. The system then faults during initialization, commonly around init_idle, sched_init, or start_kernel, resulting in an early kernel panic or boot failure. This is best treated as a local or supply-chain/update-path availability issue rather than a remotely triggerable runtime exploit.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the MIPS workaround for the LLVM $gp global register variable behavior. Where exact fixed package versions are not available, use the latest stable kernel updates from the relevant distribution, hardware vendor, or appliance vendor and confirm their advisories identify the MIPS relocation/$gp workaround. For internally built kernels, rebuild MIPS kernels with the upstream fix applied; alternatively, avoid affected LLVM versions for MIPS kernel builds by using GCC or a compiler version confirmed to contain the LLVM-side fix. Validate the full firmware or OS image, not only the kernel source tree, because the issue is tied to compiler-generated code. Maintain a tested rollback image for MIPS devices before deploying kernel updates at scale.

How to confirm the fix worked

Confirm exposure by checking whether any deployed or candidate MIPS Linux kernel was built with LLVM/Clang versions in the affected range, reported as at least 18 through 21, and whether the kernel source includes the workaround for assigning $gp during relocation. Validate remediation by boot-testing the rebuilt or vendor-fixed kernel on representative MIPS hardware or emulation and confirming the system reaches normal userspace without early Oops/panic output. Review boot console, serial console, pstore, netconsole, BMC logs, or hypervisor console output for absence of early faults in init_idle, sched_init, start_kernel, or relocate_kernel. For build pipelines, record compiler identity and version in build metadata and block promotion of unfixed MIPS kernel artifacts compiled with affected LLVM versions.

Typical attack path

1. Identify a MIPS-based Linux system or product that accepts kernel, firmware, or boot image updates.
2. Determine or cause the kernel to be built with an affected LLVM compiler version, reported as LLVM 18 through 21, without the kernel workaround.
3. Get the affected kernel image deployed through local access, administrative update mechanisms, compromised build infrastructure, malicious firmware packaging, or boot media manipulation.
4. Trigger or wait for a reboot into the affected kernel.
5. The kernel mismanages the MIPS $gp register during relocation and later dereferences invalid early-boot state.
6. The system crashes during early initialization and remains unavailable until rolled back, rebuilt, or recovered.

How to detect it

This issue is most likely observed as failed boot rather than post-compromise activity. To determine whether it already affected systems, review early boot logs from serial consoles, BMC or management controllers, hypervisor consoles, netconsole, pstore/ramoops, crash dumps, firmware update logs, and fleet availability telemetry. Look for kernel Oops or panic output immediately after boot on MIPS or Loongson systems, especially faults in init_idle, sched_init, or start_kernel following kernel relocation. Correlate boot failures with recent kernel or firmware updates and build records showing LLVM/Clang 18, 19, 20, or 21. There are no reliable network IOCs for exploitation because the failure occurs during early local boot, but repeated boot loops after deploying a MIPS kernel built with affected LLVM versions are strong operational indicators.

• CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000
• epc == ffffffff81afada8
• init_idle+0x130/0x270
• init_idle+0x118/0x270
• sched_init+0x5c8/0x6c0
• start_kernel+0x27c/0x7a8
• Process swapper (pid: 0
• Hardware name: loongson,loongson64v-4core-virtio
• PrId : 00006305 (ICT Loongson-3)
• BadVA : 0000000000000000
• Cause : 00000008 (ExcCode 02)
• Tainted: G W
• __current_thread_info
• relocate_kernel
• LLVM 18
• LLVM 19
• LLVM 20
• LLVM 21
• clang version 18
• clang version 19
• clang version 20
• clang version 21

What your security team should do

• Inventory MIPS-based Linux systems, appliances, firmware images, and internally maintained kernel build pipelines.
• Prioritize systems that recently received kernel, firmware, or boot image updates built with LLVM/Clang 18 through 21.
• Obtain vendor guidance or kernel packages that include the MIPS $gp relocation workaround; where self-building, apply the upstream patch and rebuild.
• Temporarily use GCC or a compiler version confirmed not to exhibit this LLVM behavior for MIPS kernel builds if the kernel workaround is not yet available.
• Require boot validation in staging or hardware-in-the-loop testing before promoting MIPS kernel images to production or customer-facing devices.
• Preserve recovery paths, including known-good boot partitions, console access, and rollback firmware, before deployment.
• Monitor boot failure telemetry, serial console logs, pstore records, and device availability alerts after kernel or firmware updates.
• Treat unexpected vulnerable kernel deployment as a potential build-chain or update-process incident and review who or what introduced the affected artifact.