Linux Kernel CVE-2026-80560

Exploitation requires a low-privileged local account with the ability to execute code on a Linux system running the OpenRISC (or1k) architecture - either on real or1k hardware or under qemu-system-or1k emulation. No special application configuration, non-default kernel settings, or specific kernel build options are required; the flaw is present in the baseline OpenRISC signal return path for all process contexts. Exploitation is bounded by three hard limits: (1) the target kernel must be compiled for the OpenRISC architecture - this flaw does not exist on x86, ARM, RISC-V, or any other architecture; (2) the attacker must have local code execution (not exploitable remotely); and (3) the attacker must be able to receive signals in their process, which is universally true for any unprivileged user process. No authentication beyond a local shell account is required.

The CVSS 7.8 score (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) is well-calibrated: a low-privileged local user can exploit this with straightforward signal-frame manipulation and no assistance from other users or processes. Attack complexity is genuinely low - the technique requires only the ability to register a signal handler and invoke rt_sigreturn with a crafted frame, a capability available to any unprivileged process. No EPSS data was provided in the input, so probability-of-exploitation quantification is unavailable. The vulnerability is not in CISA KEV and no public exploit has been released, though the fix description confirms a working PoC was developed for patch validation on qemu-system-or1k. SSVC assessment: Exploitation=Proof-of-Concept (confirmed in fix description, not publicly released), Automatable=No (requires interactive or scripted local code execution), Technical Impact=Total (arbitrary physical memory access bypasses all kernel memory protections). The decisive moderating factor is architecture specificity: the flaw exists only in arch/openrisc/kernel/signal.c and is not present on x86, ARM, RISC-V, or other architectures. OpenRISC has an extremely limited production footprint, confining real-world exposure to embedded development boards, academic research systems, and QEMU-based or1k emulation environments. For those environments, however, impact is severe and patching should be treated as urgent.

An unprivileged user with a local shell on an OpenRISC system registers a signal handler, then on receipt of a signal constructs a malicious sigframe on the stack with the SPR_SR_DME bit cleared in the saved SR field before calling rt_sigreturn. After the kernel restores the crafted SR to hardware via l.rfe, the CPU performs no virtual-to-physical translation on data accesses, allowing the process to directly read and write physical memory - including the kernel's own data structures at arbitrary addresses - achieving full privilege escalation. The fix description confirms this exact sequence was demonstrated with a PoC writing to physical address 0x03000000, beyond the kernel's mapped region.