{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98396 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98396 is a vulnerability in Linux, published on 14 Oct 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-98396 and fix it if it is affected.\n\nWhat it is: CVE-2026-98396 is a vulnerability in Linux, published on 14 Oct 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-98396 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-98396/ (Markdown: https://insights.sbomify.com/CVE-2026-98396/index.md)","id":"CVE-2026-98396","markdown":"https://insights.sbomify.com/CVE-2026-98396/index.md","name":"CVE-2026-98396","record":{"aliases":["DEBIAN-CVE-2026-98396","GHSA-mcv3-v2qm-396p","UBUNTU-CVE-2026-98396"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["security_bypass"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A logic error in the Linux kernel PowerPC architecture allows premature restoration of user memory access permissions, bypassing Kernel User Access Prevention protections.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare()\n\nKUAP means kernel cannot touch user memory unless it explicitly is\nenabled. In the kernel it should stay AMR_KUAP_BLOCKED. While returning\nto userspace just before RFI, kernel should restore the user AMR value\nback.\n\nLooks like GENERIC_ENTRY might be treating arch_exit_to_user_mode_prepare()\nas the last architecture step before returning to userspace.\ncommit bee25f97ad24 (\"powerpc: Enable GENERIC_ENTRY feature\")\ntherefore called kuap_user_restore() from that hook. But on PowerPC that\nis too early. After irqentry_exit() / syscall_exit_to_user_mode() we\nstill run platform specific exit routines.\n\ne.g. code snippets showing both exception handling and system call\nhandling as the callers of function arch_exit_to_user_mode_prepare()\nwhich does kuap_user_restore(). The below path shows that calling\nkuap_user_restore() is too early when called from\narch_exit_to_user_mode_prepare().\n\nException handling in exceptions-64s.S\n=======================================\n\nbl\tCFUNC(do_page_fault)\n\t  ..DEFINE_INTERRUPT_HANDLER_ASYNC(do_page_fault)\n\t      arch_interrupt_async_enter_prepare(regs);\n\t      state = irqentry_enter(regs);\n\t      instrumentation_begin();\n\t      irq_enter_rcu();\n\t      handler(regs);\n\t      nap_adjust_return(regs);\n\t      irq_exit_rcu();\n\t      instrumentation_end();\n\t      arch_interrupt_async_exit_prepare(regs);\n\t      irqentry_exit(regs, state); \t\t   \u003c\u003c\u003c too early\n\t        irqentry_exit_to_user_mode()\n\t\t  __exit_to_user_mode_prepare(regs, EXIT_TO_USER_MODE_WORK_IRQ);\n\t\t    arch_exit_to_user_mode_prepare(regs, ti_work);  \u003c\u003c\u003c too early\nb\tinterrupt_return_srr\n\t\t.. bl\tCFUNC(interrupt_exit_user_prepare) \u003c\u003c\u003c already calls kuap_user_restore\n\nprep_irq_for_enabled_exit() retry can run kernel code with IRQs on. So\nonly when that routine is fully finished is when the user KUAP should be\nfully restored which interrupt_exit_user_prepare() already takes care of\nbefore returning.\n\nSimilarly for system call handling in interrupt_64.S\n======================================================\n\n\tbl\tCFUNC(system_call_exception)\n\n.Lsyscall_exit:\n\taddi\tr4,r1,STACK_INT_FRAME_REGS\n\tli\tr5,0 /* !scv */\n\tbl\tCFUNC(syscall_exit_prepare)\n\t\t  .. kuap_assert_locked();\n\t\t     syscall_exit_to_user_mode(regs); \u003c\u003c\u003c too early\n\t\t       syscall_exit_to_user_mode_prepare(regs);  \u003c\u003c\u003c too early\n \t\t     kuap_user_restore(regs);         \u003c\u003c\u003c already calls\n\nsyscall_exit_prepare(), which can enable IRQs, replay a pending\ninterrupt, and only then rfi. Those functions already restore KUAP\nimmediately before rfi.\n\nNote that if we restore the user AMR too early like in the current code\nas shown from the code snippets above, then we get the following warning\nwhen CONFIG_PPC_KUAP_DEBUG is enabled:\n  WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interrupt_exit_user_prepare+0x1a0/0x1c0\n  Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected)\n  TRAP: 0700\n  LR: c00000000000d8d4 CTR: c0000000021fe500\n  MSR: \u003cSF,EE,ME,IR,DR,RI,LE\u003e  CR: 44000804  XER: 20040000\n  interrupt_exit_user_prepare+0x1a0/0x1c0\n  interrupt_return_srr_user+0x8/0x12c","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":"powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare()","id":"CVE-2026-98396","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":0,"n_references":2,"next":{"headline":"platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown","id":"CVE-2026-98397"},"packages":[],"prev":{"headline":"powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit","id":"CVE-2026-98395"},"products":["Linux"],"published":"2026-10-14","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A logic error in the Linux kernel PowerPC architecture allows premature restoration of user memory access permissions, bypassing Kernel User Access Prevention protections.","url":"https://insights.sbomify.com/CVE-2026-98396/"}