CVE-2026-89489
nicheLinux OpenRISC: unchecked pointers in or1k_atomic syscall allow kernel read/write
The sys_or1k_atomic() syscall (number 244 in the OpenRISC or1k ABI) swaps 32-bit words at two caller-supplied pointers, but never validates them with access_ok(), and its hand-written assembly lacks exception-table fixups. A local unprivileged process can pass a kernel address as either pointer to obtain a direct kernel read/write primitive — for example, overwriting the sys_call_table to gain code execution in kernel context, which amounts to full privilege escalation to root. Only systems running Linux built for the OpenRISC (or1k) architecture are affected, since this syscall exists only in the or1k ABI. The fix validates both pointers before the critical section and adds fixups so faults on valid-but-unmapped user addresses return -EFAULT. No public proof of concept is known, and there is no evidence of exploitation in the wild.
What to do: Patch OpenRISC (or1k) systems to a kernel containing the fix, which adds access_ok() checks on both pointers and exception-table fixups that return -EFAULT on faults. If immediate patching is not possible, restrict syscall 244 for untrusted local processes via seccomp. Mainstream x86 and ARM deployments are unaffected because this syscall exists only in the or1k ABI, but any or1k system reachable by untrusted local users should be treated as fully compromisable.
| Linux kernel project Linux kernel (OpenRISC / or1k architecture port) | All kernel versions containing the or1k_atomic syscall, prior to the fixing commit (no specific version range stated in the advisory data) |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [[email protected]: fix comment style]
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.