CVE-2026-80560: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-80560 Overview

CVE-2026-80560 is a local privilege escalation vulnerability in the Linux kernel's OpenRISC (or1k) signal handling code. The restore_sigcontext() function copies the entire Supervision Register (SR) from a user-controlled signal frame and only masks SPR_SR_SM before reloading the value into the hardware SR through ESR and l.rfe on return to user space. All other privileged SR bits remain under user control. An unprivileged task can craft a signal frame that clears SPR_SR_DME, disabling the data Memory Management Unit (MMU) and gaining read/write access to arbitrary physical memory.

Critical Impact
An unprivileged local user on OpenRISC systems can escalate to full kernel-level access to physical memory by returning from a signal handler with a crafted sigframe.

Affected Products

Linux kernel on the OpenRISC (or1k) architecture
Stable branches referenced in kernel commits 212fc482, 32ef1b30, 89a91b30, a88d688b, b4d73c38, bc2e24ba, cd8b43a7, and cf1b5514
Systems running unpatched OpenRISC Linux builds (verified against qemu-system-or1k -M or1k-sim)

Discovery Timeline

2026-08-26 - CVE-2026-80560 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-80560

Vulnerability Analysis

The OpenRISC signal return path restores CPU state from a signal frame stored in user memory. In the vulnerable implementation, restore_sigcontext() copies the full SR value from the user-supplied sigframe and clears only the supervisor mode bit (SPR_SR_SM) before the register is reloaded into hardware via the exception SR (ESR) and the l.rfe return-from-exception instruction. Every other control bit in the SR is preserved from the attacker-supplied value.

Because the SR governs MMU state, cache behavior, and exception handling on OpenRISC, allowing user space to control these bits collapses the kernel/user protection boundary. The ptrace general-purpose register regset already rejects SR modifications for this exact reason, but the signal return path did not enforce the same restriction. This is a kernel vulnerability in the privileged-bit restoration logic of an architecture-specific signal handler.

Root Cause

The root cause is missing sanitization of privileged fields when restoring CPU state from a user-controlled structure. restore_sigcontext() should treat the SR as split between arithmetic flag bits (F, CY, OV), which are safe to restore from user space, and privileged control bits, which must be sourced from the kernel-saved SR captured on signal entry. The fix restricts user-restorable bits to the arithmetic flags and takes every privileged control bit from the kernel's saved copy.

Attack Vector

An unprivileged local process installs a signal handler and arranges to be interrupted by any signal. Inside the handler, or via rt_sigreturn with a forged frame, the attacker writes an SR value that clears SPR_SR_DME to disable the data MMU. On return through l.rfe, the CPU resumes user execution with data translation and protection disabled, giving the process direct access to physical memory. The same technique exposes SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH, and the cache-enable bits. A published proof-of-concept clears SPR_SR_DME and writes a marker to physical address 0x03000000, beyond the kernel's mem=32M allocation.

// No verified exploit code available - refer to upstream commits for technical detail
// See: https://git.kernel.org/stable/c/cf1b5514ddf9df098ce7e3741fc9679fd85a4ec6

Detection Methods for CVE-2026-80560

Indicators of Compromise

Unexpected user-space processes performing reads or writes to physical addresses outside their virtual mappings, observable as anomalous page-fault patterns or kernel warnings on OpenRISC targets.
Kernel logs showing exceptions or oopses originating from l.rfe or restore_sigcontext code paths on or1k builds.
Local processes issuing frequent rt_sigreturn calls with atypical sigframe contents on OpenRISC hosts.

Detection Strategies

Audit kernel version and architecture inventory to identify OpenRISC builds predating the fix commits listed in the kernel.org references.
Enable auditd rules on rt_sigreturn and monitor for anomalous frequency or origin from non-privileged binaries on affected systems.
Correlate signal-return activity with subsequent memory-access anomalies or kernel exceptions to identify exploitation attempts.

Monitoring Recommendations

Ship kernel logs and syscall telemetry from OpenRISC hosts into a centralized logging pipeline for behavioral analysis.
Alert on any kernel exception, panic, or BUG: message emitted from OpenRISC signal-handling code paths.
Track unexpected process privilege transitions or memory-map changes on embedded and simulator-based OpenRISC deployments.

How to Mitigate CVE-2026-80560

Immediate Actions Required

Apply the upstream Linux kernel patches that restrict restore_sigcontext() to restoring only the SR arithmetic flag bits (F, CY, OV) from the sigframe.
Rebuild and redeploy OpenRISC kernels using one of the fix commits: 212fc48, 32ef1b30, 89a91b30, a88d688b, b4d73c38, bc2e24ba, cd8b43a7, or cf1b5514.
Restrict local shell and code-execution access on OpenRISC systems until patched kernels are deployed.

Patch Information

The fix modifies restore_sigcontext() in the OpenRISC signal code to restore only the arithmetic flag bits from the signal frame and take every privileged control bit from the SR value the kernel saved on signal entry. This mirrors the existing ptrace GPR regset policy that already refuses SR modifications. The change was verified under qemu-system-or1k -M or1k-sim, where a proof-of-concept that previously cleared SPR_SR_DME and wrote to physical address 0x03000000 now receives SIGSEGV with physical memory unchanged.

Workarounds

No supported runtime workaround exists; the SR bit-masking logic is inside the kernel signal-return path and requires a kernel rebuild.
Where patching is delayed, limit OpenRISC systems to trusted local users and remove unnecessary interactive login access.
Isolate OpenRISC workloads on dedicated hardware or virtual machines to contain the impact of local privilege escalation.

bash

# Verify kernel commit is present after patching
git -C /path/to/linux log --oneline | grep -E '212fc48|cf1b5514|cd8b43a7'
uname -r