CVE-2026-43212

What it actually does

This is a local Linux kernel privilege-escalation flaw affecting the LoongArch architecture. The vulnerable architecture-specific implementation of cpumask_of_node() does not safely handle NUMA_NO_NODE, even though that value can be passed as a valid sentinel for “no NUMA node.” If a reachable kernel code path passes NUMA_NO_NODE into this helper, the kernel can reference an invalid CPU mask or otherwise behave incorrectly. Depending on the reachable path and memory layout, this may lead to kernel memory corruption, kernel crash, or potential execution of attacker-controlled behavior in kernel context. Because the bug is local and requires low-privileged access, the primary technical risk is escalation from an ordinary local account or process to full kernel/root privileges on affected LoongArch systems.

Why it matters to the business

Successful exploitation could allow a user or compromised local workload on an affected LoongArch Linux system to gain full control of the host, read or modify sensitive data, disable security controls, or disrupt availability through a kernel crash. The issue is not known to be exploited in the wild, is not listed in CISA KEV, has no reported ransomware association, and has a low, stable EPSS score, so broad opportunistic exploitation is currently unlikely. The risk is highest for organizations running multi-user LoongArch servers, shared compute platforms, or systems where untrusted local code can execute.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected LoongArch Linux system, such as through a shell account, compromised application process, container escape precondition, or malicious workload. The attacker then exercises a kernel interface or subsystem path that can cause NUMA_NO_NODE to be passed into the LoongArch cpumask_of_node() implementation. Because the vulnerable implementation does not guard against that sentinel value, the kernel may access an invalid CPU mask or operate on unintended memory. A reliable exploit would attempt to shape kernel memory and repeatedly trigger the faulty path to convert the invalid access into controlled memory corruption, ultimately escalating privileges to root or kernel-level execution. Less reliable attempts may simply cause an Oops or panic, resulting in denial of service.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the LoongArch fix making cpumask_of_node() robust against NUMA_NO_NODE. No exact fixed package versions were provided, so remediation should be based on vendor advisories, distribution security errata, or upstream kernel commits containing this change. Prioritize LoongArch systems, especially those allowing local user access or running untrusted workloads. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted code execution, isolating workloads, enforcing least privilege, enabling kernel hardening features supported by the distribution, and monitoring for kernel Oops/panic events. Reboot into the fixed kernel after installation; merely installing the package is insufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the system is running on LoongArch and is using a kernel build that includes the cpumask_of_node() NUMA_NO_NODE fix. Validate both the installed kernel package and the active running kernel using standard distribution tools such as uname -r and package-manager security advisory checks. Review vendor changelogs or kernel source patches for the LoongArch cpumask_of_node() guard against NUMA_NO_NODE. After updating, reboot and verify the active kernel version changed to the fixed build. For source-based or custom kernels, inspect the LoongArch architecture implementation of cpumask_of_node() and confirm it explicitly handles NUMA_NO_NODE safely. Also confirm there are no recent kernel Oops, panic, or stack traces involving cpumask_of_node() after the update.

Typical attack path

1. Obtain local code execution on an affected LoongArch Linux system with low privileges.
2. Identify a reachable kernel interface or subsystem path that can pass NUMA_NO_NODE to cpumask_of_node().
3. Trigger the vulnerable path repeatedly while observing kernel behavior for crashes, warnings, or memory corruption.
4. If exploitable beyond denial of service, shape kernel memory to influence the invalid cpumask access.
5. Use the resulting kernel memory corruption or control-flow influence to gain elevated privileges.
6. Execute post-exploitation actions as root or kernel context, such as disabling controls, accessing protected data, or installing persistence.

How to detect it

There are no public exploit-specific indicators provided, and this issue is not currently known to be exploited in the wild. Detection should focus on evidence of attempted local kernel exploitation and instability on LoongArch systems. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump facilities for Oops, panic, invalid memory access, or stack traces involving cpumask_of_node(), LoongArch NUMA code, or NUMA_NO_NODE handling. Correlate such events with local user activity, recently started processes, suspicious binaries in temporary directories, privilege changes, new setuid files, unexpected root shells, kernel module load attempts, or abnormal container/workload behavior. If crash dumps are available, inspect call traces for cpumask_of_node() and related scheduler, NUMA, or CPU-mask handling paths. Because exploitation requires local execution, endpoint telemetry showing an unprivileged process followed by kernel crash, privilege escalation, or root-owned process creation is more meaningful than network telemetry.

• cpumask_of_node
• NUMA_NO_NODE
• LoongArch
• kernel: Oops
• kernel: Kernel panic
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request

What your security team should do

• Inventory LoongArch Linux systems and determine which kernels are affected.
• Prioritize patching systems that allow local users, shared compute, CI/CD runners, research workloads, or other untrusted code execution.
• Install vendor-provided fixed kernels and reboot systems into the patched kernel.
• If patching is delayed, restrict local access and isolate workloads to reduce the chance that a low-privileged process can reach vulnerable kernel paths.
• Monitor kernel logs for Oops, panic, general protection faults, or stack traces referencing cpumask_of_node() or LoongArch NUMA handling.
• Track distribution advisories for exact fixed package versions because none were provided in the input.
• Treat any unexplained local privilege escalation or kernel crash on affected LoongArch systems as potentially security-relevant and preserve logs for investigation.