{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89581 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89581 is a high-severity memory corruption vulnerability in Linux, published on 11 Sep 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-89581 and fix it if it is affected.\n\nWhat it is: CVE-2026-89581 is a high-severity memory corruption vulnerability in Linux, published on 11 Sep 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-89581 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-89581/ (Markdown: https://insights.sbomify.com/CVE-2026-89581/index.md)","id":"CVE-2026-89581","markdown":"https://insights.sbomify.com/CVE-2026-89581/index.md","name":"CVE-2026-89581","record":{"aliases":["BELL-CVE-2026-89581","DEBIAN-CVE-2026-89581","GHSA-vx2x-82ww-5r7r","UBUNTU-CVE-2026-89581"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","code_execution"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel BPF","requires_auth":"low_privilege","summary":"A Linux kernel BPF JIT bug causes incorrect register usage for per-CPU addresses, leading to kernel panics and potential memory corruption.","user_interaction":"not_required","vuln_class":"memory_corruption"},"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\nbpf, x86: Fix per-CPU address resolution into an extended register\n\nThe destination of the per-CPU address MOV is encoded in ModRM.reg,\nwhich is extended by REX.R, but the REX prefix is built with\nadd_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and\nthis instruction addresses memory as disp32 with no base, so the bit\nhas no effect at all and the high register bit is simply lost.\n\nEvery is_ereg() destination therefore resolves to the wrong register,\npicking whichever one shares the low three bits:\n\n  R5 -\u003e RAX    R7 -\u003e RBP    R8 -\u003e RSI    R9 -\u003e RDI\n\nWith BPF_REG_5, whose reg2hex is 0, the emitted\n\n  65 49 03 04 25 \u003coff\u003e\tadd %gs:\u003coff\u003e,%rax\n\nadds the per-CPU offset to RAX rather than R8. The destination keeps\nthe unadjusted address and RAX is clobbered, so the program goes on to\ndereference a pointer that was never made per-CPU:\n\n  BUG: unable to handle page fault for address: 0000607e386a8894\n  RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9\n  Call Trace:\n   __bpf_prog_test_run_raw_tp+0x2dc/0x7d0\n   __flush_smp_call_function_queue+0x1e9/0xc80\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nR5 is the mildest of the four, aliasing a scratch register and faulting\nat the store. R7 aliases RBP and would corrupt the frame pointer, R8\nand R9 alias the argument registers.\n\nUse add_2mod() so the register goes through REX.R, matching how\nadd_2reg() places it in ModRM.reg and how emit_priv_frame_ptr()\nhardcodes 0x4c for the same instruction with R9. Encodings for the\nnon-extended registers are unchanged.\n\nProblem showed up when trying to resurrect BPF_GCC CI (selftests built\nwith BPF_GCC).\n\nThis has gone unnoticed because clang reloads the address into R1\nbefore each per-CPU access, so the destination is never an extended\nregister. GCC keeps several per-CPU addresses live at once, and\ntest_progs-bpf_gcc panics the kernel in global_percpu_data/init, where\nthe address of a .percpu variable ends up in R5.","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":"bpf, x86: Fix per-CPU address resolution into an extended register","id":"CVE-2026-89581","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"bnx2x: fix double free in bnx2x_init_firmware() error path","id":"CVE-2026-89582"},"packages":[],"prev":{"headline":"bpf: Disable preemption in __bpf_get_stack","id":"CVE-2026-89580"},"products":["Linux"],"published":"2026-09-11","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-10-19","vendors":["Linux"]},"summary":"A Linux kernel BPF JIT bug causes incorrect register usage for per-CPU addresses, leading to kernel panics and potential memory corruption.","url":"https://insights.sbomify.com/CVE-2026-89581/"}