CVE-2026-64082

What it actually does

This Linux kernel flaw affects RISC-V compatibility register handling. In two error paths, the kernel may convert and write an uninitialized stack-based register structure into a task's saved register state after a failed user-memory copy. A local user with the ability to exercise the affected interfaces can cause corruption of the target task's pt_regs state and may expose kernel stack contents through corrupted register values. Because register state controls execution context, the impact can include information disclosure, integrity corruption of process execution state, and denial of service through crashes or unstable task behavior.

Why it matters to the business

Systems running affected Linux kernels on RISC-V hardware may be exposed to local privilege-bound attacks that can leak sensitive kernel memory or destabilize workloads. The issue is not known to be exploited in the wild, is not listed in CISA KEV, and currently has a low EPSS score, so broad internet-scale exploitation is unlikely; however, shared compute, multi-user systems, build farms, edge devices, and appliances using RISC-V Linux kernels should treat it as important because a local attacker or compromised low-privilege process could use it to weaken system isolation or disrupt operations.

How an attack unfolds

An attacker first needs local code execution with ordinary user privileges on a vulnerable RISC-V Linux system. They then trigger one of the affected compatibility paths with deliberately failing user-space memory copy behavior, such as supplying invalid or inaccessible memory during register-set manipulation or signal-return context restoration. In the vulnerable kernel, the failed copy does not stop subsequent conversion of the uninitialized compatibility register buffer. The kernel then writes stack-derived, uninitialized values into the task's saved register state. Depending on timing and surrounding kernel stack contents, this can corrupt execution flow, crash the task or system, or expose kernel stack data through observable register state. No public exploitation campaign or named threat actor activity is currently indicated by the provided data.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the RISC-V uninitialized compatibility register handling issue. The fix changes the affected paths so cregs_to_regs() is only called after user_regset_copyin() or __copy_from_user() succeeds. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, vendor appliance firmware, or upstream stable kernel branch once available. If immediate patching is not possible, reduce exposure by limiting local shell access, isolating untrusted workloads, avoiding multi-tenant use on affected RISC-V systems, enforcing least privilege, and prioritizing patching on systems where untrusted users or containers can execute code.

How to confirm the fix worked

Confirm that the running kernel includes the vendor or upstream patch for the RISC-V compat_riscv_gpr_set() and compat_restore_sigcontext() error paths. Validate using distribution security advisories, kernel changelogs, package metadata, or source inspection showing that cregs_to_regs() is only reached after successful copy operations. On managed systems, verify both the installed kernel package and the actively booted kernel version, since installing an update without rebooting may leave the vulnerable kernel in use. Where source validation is possible, inspect the relevant RISC-V kernel code paths for conditional handling of user_regset_copyin() and __copy_from_user() failures.

Typical attack path

1. Obtain local execution on a RISC-V Linux system running an affected kernel.
2. Identify whether the kernel exposes the vulnerable compatibility register or signal-return paths.
3. Invoke the affected path while causing the user-memory copy operation to fail.
4. Rely on the vulnerable error handling to process uninitialized stack data as register content.
5. Observe corrupted task register state, leaked kernel-derived values, process crashes, or other instability.
6. Use any disclosed information or corrupted execution state to support further local exploitation or denial-of-service activity.

How to detect it

There are no highly reliable remote indicators for this vulnerability because exploitation is local and occurs inside kernel task register-handling paths. Security teams should review endpoint telemetry, audit logs, and kernel logs for unusual local execution immediately preceding process crashes, kernel oops messages, signal-return anomalies, or repeated faults involving ptrace-like register manipulation. Useful log sources include kernel ring buffer output, system journal logs, auditd process execution records, EDR telemetry, crash dumps, and core-dump metadata. For forensic review, focus on RISC-V systems where untrusted users had local access and look for suspicious binaries or scripts repeatedly invoking register-set operations, signal frame manipulation, invalid memory mappings, or fault-inducing syscalls. Because no known exploitation campaign, threat actor, or public exploit maturity is indicated, absence of obvious IOCs does not prove absence of exploitation.

• compat_riscv_gpr_set
• compat_restore_sigcontext
• cregs_to_regs
• user_regset_copyin
• __copy_from_user
• kernel oops
• segfault
• SIGSEGV
• SIGILL
• ptrace

What your security team should do

• Inventory RISC-V Linux systems and determine whether they run kernels containing the vulnerable code paths.
• Prioritize updates for shared, multi-user, CI/build, edge, appliance, and container-hosting RISC-V systems.
• Apply vendor kernel or firmware updates as soon as fixed builds are available, then reboot into the fixed kernel.
• Restrict local access for untrusted users until patched, especially on systems where users can run arbitrary binaries.
• Monitor for local crash patterns, kernel warnings, or suspicious attempts to manipulate register state or signal-return behavior.
• Track distribution advisories for exact fixed kernel package versions because none were provided in the input.
• Do not rely on network controls alone; exploitation requires local execution, so endpoint hardening and access control are the primary compensating measures.