CVE-2026-45993

What it actually does

This is a Linux kernel flaw affecting the LoongArch architecture syscall dispatch path. A user-controlled syscall number can be used without an appropriate speculation barrier, allowing the CPU to speculatively index beyond the intended syscall function pointer table before architectural bounds checks take effect. The assessed impact is local denial of service: a local, low-privileged user or process may be able to trigger unstable kernel behavior or a crash, affecting system availability. The available scoring does not indicate direct confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernels on LoongArch hardware may be vulnerable to local disruption by an unprivileged user or compromised process. In practical terms, this could cause server crashes, workload interruption, loss of availability, and operational recovery effort. The issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, shared compute platforms, multi-user systems, CI runners, research clusters, and appliance-like deployments where untrusted local code can run should treat it as more urgent.

How an attack unfolds

An attacker first needs local code execution on a vulnerable LoongArch Linux system, such as access to a shell, a compromised low-privileged service account, or the ability to run an untrusted binary. The attacker then repeatedly invokes syscalls using crafted out-of-range or boundary syscall numbers intended to exercise the syscall dispatch table path. Because the syscall number originates from userspace and the affected path lacks the required array_index_nospec-style boundary protection, speculative execution may access beyond the valid syscall table range. Depending on kernel version, CPU behavior, and surrounding memory layout, this can manifest as kernel instability or a denial-of-service condition. There is no indication from the supplied intelligence that this vulnerability is remotely exploitable or currently used by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the LoongArch syscall dispatch speculation-boundary fix. Because no exact fixed package versions were provided, use the latest stable kernel from the operating system vendor, distribution security channel, or upstream-supported kernel branch for LoongArch. Prioritize updates on LoongArch systems that allow multiple users, execute untrusted workloads, host containers, run build jobs, or provide business-critical services. If immediate patching is not possible, reduce exposure by limiting local shell access, preventing execution of untrusted binaries, tightening container and sandbox boundaries, applying least-privilege controls, and ensuring watchdog/reboot procedures are in place for availability recovery. These mitigations reduce attack opportunity but do not correct the kernel flaw.

How to confirm the fix worked

Confirm exposure by checking whether systems are LoongArch-based and running a kernel version/build that predates the vendor fix. Validate remediation by installing the vendor-fixed kernel, rebooting into it, and confirming the active runtime kernel with standard host inventory commands such as `uname -a` and package-manager queries. Review the distribution kernel changelog or advisory for references to the LoongArch syscall dispatch table, syscall number bounds handling, `array_index_nospec`, or Spectre boundary fixes. Where kernel live patching is used, confirm that the live patch specifically covers this LoongArch syscall dispatch change; otherwise a reboot into a fixed kernel is required. Do not rely on network vulnerability scanners alone, because exploitation requires local execution and architecture-specific kernel state.

Typical attack path

1. Gain local ability to execute code on a LoongArch Linux system.
2. Identify that the host is running an affected kernel build on the LoongArch architecture.
3. Run a program that issues crafted syscall numbers near or beyond the valid syscall table range.
4. Repeat calls to increase the chance of triggering unstable kernel behavior.
5. Cause a kernel oops, panic, hang, or reboot, resulting in denial of service.

How to detect it

There are no known public exploit indicators, named threat actors, KEV listing, or ransomware association for this issue based on the supplied data. Exploitation is local and may leave little or no application-level evidence unless it causes a kernel fault, hang, panic, or reboot. Review persistent system journals, kernel ring buffers, console logs, crash dumps, kdump/vmcore artifacts, hypervisor reset events, and EDR process telemetry for suspicious low-privileged processes making unusual syscall-heavy activity shortly before a crash. On Linux, useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/crash/`, `/var/lib/systemd/coredump/`, kdump storage locations, auditd `execve` records, container runtime logs, and host uptime/reboot history. Look for repeated local executions of test binaries or fuzzers followed by LoongArch kernel oops/panic messages. Absence of these artifacts does not prove non-exploitation, because failed or successful triggering may not produce a distinctive log entry before the system becomes unavailable.

• array_index_nospec
• syscall dispatch table
• sys_call_table
• Kernel panic - not syncing
• Oops
• Unable to handle kernel
• BadVA
• do_syscall
• /var/crash/
• /var/log/kern.log
• /var/log/messages
• /proc/vmcore

What your security team should do

• Inventory LoongArch Linux systems and identify kernel versions currently running, not just installed.
• Patch affected LoongArch systems through the OS vendor’s kernel update channel and reboot into the fixed kernel.
• Prioritize multi-user, shared compute, container-hosting, CI/CD, and externally managed systems where untrusted local code may execute.
• Restrict local interactive access and untrusted binary execution until fixed kernels are deployed.
• Monitor for unexpected kernel oops, panic, hang, or reboot events on LoongArch hosts, especially following activity by low-privileged users or containers.
• Ensure crash dump collection, persistent kernel logging, and uptime/reboot telemetry are enabled to support post-incident investigation.
• Track vendor advisories for exact fixed package versions because none were supplied in the input data.