{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-80560 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-80560 is a high-severity vulnerability in Linux, published on 26 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-80560 and fix it if it is affected.\n\nWhat it is: CVE-2026-80560 is a high-severity vulnerability in Linux, published on 26 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-80560 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-80560/ (Markdown: https://insights.sbomify.com/CVE-2026-80560/index.md)","id":"CVE-2026-80560","markdown":"https://insights.sbomify.com/CVE-2026-80560/index.md","name":"CVE-2026-80560","record":{"aliases":["AZL-97788","BELL-CVE-2026-80560","DEBIAN-CVE-2026-80560","GHSA-gfrq-95rp-6g53","UBUNTU-CVE-2026-80560"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["privilege_escalation","data_read","data_modify"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"An unprivileged user can escalate privileges by crafting a signal frame to disable MMU protection, allowing arbitrary physical memory access.","user_interaction":"not_required","vuln_class":"privilege_escalation"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nopenrisc: signal: do not restore privileged SR bits on sigreturn\n\nrestore_sigcontext() copies the whole supervision register (SR) from the\nsignal frame and only clears SPR_SR_SM before the value is reloaded into\nthe hardware SR (through ESR and l.rfe) on the return to user space.  All\nother SR bits are left under user control.\n\nAn unprivileged task can thus return from a signal handler through a\ncrafted sigframe that clears SPR_SR_DME.  With the data MMU disabled the\nCPU performs no translation or protection on data accesses, so the task\ngains read and write access to arbitrary physical memory, a local\nprivilege escalation.  SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH\nand the cache-enable bits are exposed the same way.  The ptrace GPR regset\nalready refuses any change to SR for exactly this reason.\n\nRestore only the arithmetic flag bits (F, CY, OV) from the signal frame\nand take every privileged control bit from the SR the kernel saved on\nsignal entry.\n\nVerified with qemu-system-or1k -M or1k-sim: before this change an\nunprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to\nphysical address 0x03000000 (beyond the kernel's mem=32M); afterwards the\nsame PoC receives SIGSEGV and physical memory is unchanged.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"openrisc: signal: do not restore privileged SR bits on sigreturn","id":"CVE-2026-80560","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"privilege_escalation","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"libceph: fix multiple unsafe decodes in decode_locker()","id":"CVE-2026-80561"},"packages":[],"prev":{"headline":"Input: sur40 - fix input device registration ordering","id":"CVE-2026-80559"},"products":["Linux"],"published":"2026-08-26","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-27","vendors":["Linux"]},"summary":"An unprivileged user can escalate privileges by crafting a signal frame to disable MMU protection, allowing arbitrary physical memory access.","url":"https://insights.sbomify.com/CVE-2026-80560/"}