CVE-2026-89489

What it actually does

On OpenRISC (or1k) Linux kernels, sys_or1k_atomic (syscall 244) swaps 32-bit words at two caller-supplied pointers in hand-written assembly without access_ok() checks or exception-table fixups. An unprivileged local process can therefore read and write arbitrary kernel virtual memory, including control structures such as the system-call table, yielding a kernel read/write primitive and local privilege escalation to kernel context. Faults on unmapped user addresses can also panic rather than returning -EFAULT. Non-OpenRISC architectures are not affected.

Why it matters to the business

Any untrusted local account on a Linux system running the OpenRISC kernel ABI can take full control of the host, enabling data theft, persistent implants, and workload disruption. Impact is limited to OpenRISC hardware and emulators; mainstream x86/ARM fleets are out of scope. Exploit maturity is none, EPSS is very low and flat (~0.0014 over 30 days), and the issue is not in CISA KEV and is not associated with ransomware, so mass exploitation is not indicated. Residual operational risk is concentrated on OpenRISC embedded, research, and development systems that still allow untrusted local users. The issue has been public for about 33 days; those in-scope hosts should still be patched, but this should not displace higher-urgency KEV work.

How an attack unfolds

A local attacker who can already run unprivileged code on a vulnerable OpenRISC Linux kernel invokes the architecture-specific atomic-swap syscall with pointer arguments that refer to kernel addresses instead of userspace. The kernel performs the loads and stores without validating the pointers, giving the attacker an arbitrary kernel read/write primitive. The attacker uses that primitive to inspect kernel memory and overwrite control data such as the system-call table or other function pointers. Later kernel paths then execute attacker-controlled code with kernel privileges, completing local privilege escalation. No in-the-wild campaigns, named threat actors, or public exploit code are associated with this issue.

How to fix it

Apply the upstream Linux kernel fix for OpenRISC that validates both sys_or1k_atomic pointers with access_ok() before the critical section and adds exception-table fixups so invalid user addresses return -EFAULT instead of panicking or touching kernel memory. Upgrade to a distribution or vendor kernel that includes that change. No specific fixed package versions were supplied with this record; use your distro security tracker and kernel changelog to confirm the or1k_atomic pointer-check patch is present. Until patched, restrict local logins and untrusted code execution on OpenRISC hosts and avoid multi-tenant use. Systems not running the OpenRISC kernel ABI require no change for this CVE.

How to confirm the fix worked

Confirm architecture with uname or equivalent (in-scope only if OpenRISC/or1k). Verify the running kernel package changelog or upstream commit includes the sys_or1k_atomic access_ok() checks and exception-table entries. After upgrade, confirm the syscall rejects kernel addresses and returns an error on unmapped but otherwise valid user pointers rather than swapping kernel memory or oopsing. Mark non-OpenRISC kernels not applicable. Do not validate by attempting kernel-address writes on production systems.

Typical attack path

1. Obtain local unprivileged execution on a Linux host using the OpenRISC (or1k) kernel ABI
2. Invoke the or1k atomic-swap syscall with pointers into kernel address space
3. Use the unchecked kernel loads and stores to leak kernel memory and identify overwrite targets
4. Corrupt kernel control structures (for example the system-call table or related function pointers)
5. Trigger kernel use of the corrupted pointers to run code in kernel context and take full control of the host

How to detect it

No public exploit, malware family, or named campaign is tied to this issue, so confirmed compromise artifacts are unlikely to be unique. Hunt only on OpenRISC Linux hosts: unexplained unprivileged-to-root transitions without a matching sudo, su, or polkit event; kernel oops/panic logs involving syscall or atomic handling; integrity-monitor or hypervisor alerts for unexpected writes to kernel text or the system-call table; and audit or syscall traces showing unusual use of syscall number 244 (or1k_atomic) from unprivileged processes. Review process accounting around any unexplained root shells. Userspace file hashes are not expected to be distinctive because the primitive is a direct kernel read/write. Absence of these signals does not prove the host was never abused.

What your security team should do

• Inventory Linux hosts and treat only OpenRISC/or1k kernels as in-scope; close or not-applicable all other architectures
• Patch in-scope kernels to a build that includes the or1k_atomic pointer-validation and exception-table fix as soon as the vendor publishes it
• Until patched, remove untrusted local users and disable untrusted code execution on those hosts
• Track distribution kernel advisories for exact package versions, which were not listed in this record
• Given no KEV listing, no ransomware use, no known exploitation, and a flat low EPSS, do not pull effort from higher-urgency KEV items, but do not leave identified OpenRISC systems unpatched