{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98869 in the wild and no public exploit code.","fix":"No fix has been published for CVE-2026-98869 yet. Limit exposure of the affected software until one is available.","what":"CVE-2026-98869 is a high-severity vulnerability in Linux, published on 21 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-98869 and fix it if it is affected.\n\nWhat it is: CVE-2026-98869 is a high-severity vulnerability in Linux, published on 21 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-98869 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-98869/ (Markdown: https://insights.sbomify.com/CVE-2026-98869/index.md)","id":"CVE-2026-98869","markdown":"https://insights.sbomify.com/CVE-2026-98869/index.md","name":"CVE-2026-98869","record":{"aliases":["BELL-CVE-2026-98869","DEBIAN-CVE-2026-98869","GHSA-m2xx-ffwm-822c","UBUNTU-CVE-2026-98869"],"analysis":null,"analysis_generated_by":null,"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: Infer zext_dst based on static register liveness analysis\n\nAs reported in the thread [1], the verifier's 32-bit operations zero\nextension logic is broken. This logic is responsible for correct\nsemantics of 32-bit operations on s390 architecture.\n\nAccording to BPF semantics, operation `w1 += 1` is supposed to zero\nextend the upper half of the register `r1`. On s390 the JIT relies on\nthe verifier emitting explicit zero extension before such operations.\n\nThe verifier attempts to minimize the amount of zero extensions\ninserted by tracking whether upper halves of the 64-bit registers are\never used. Previously such tracking worked as follows:\n\n- bpf_reg_state-\u003esubreg_def field was set by do_check_insn()\n  for each operation defining lower but not the upper halves\n  of the register.\n- Whenever an operation reading the whole register was verified,\n  the verifier checked register's subreg_def and set\n  bpf_insn_aux_data-\u003ezext_dst flag as true via a call to\n  mark_insn_zext() function.\n- After the verification was complete, a special pass\n  bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations\n  with bpf_insn_aux_data-\u003ezext_dst set as true by adding\n  explicit zero extension.\n\nNote that the logic above relies on bpf_reg_state-\u003esubreg_def,\nwhich is a property of a current verifier state.\nBefore the commit [2] two additional steps happened:\n\n- The verifier tracked upper and lower register halves' liveness as\n  flags REG_LIVE_READ{32,64} in bpf_reg_state-\u003elive.\n- The function propagate_liveness() called mark_insn_zext()\n  in order to transfer the knowledge about which registers have\n  their upper halves alive (and thus might require zero extension).\n\nThe commit [2] removed the two steps described above,\nhence making possible a situation like below:\n\n- The register's upper half is set and is used on some verification\n  path P1 and the register happens not to be marked as precise.\n- The checkpoint C is created while processing some instruction\n  between register initialization and usage.\n- On some other verification path P2 the register's upper half is not\n  initialized and that path ends hitting the checkpoint C.\n- In such a case the register's initialization on path P2 would lack\n  zext_dst mark, making it possible for the program to inject\n  an arbitrary value in the register's upper half.\n\nThis commit replaces subreg_def based logic with computing zext_dst\nstatically, as a part of the bpf_compute_live_registers() analysis:\n\n- The analysis now tracks usage of upper and lower halves of the\n  registers separately.\n- If some instruction defines a 32-bit subregister, but not the whole\n  register, *and* the upper half of the register is alive after that\n  instruction, the instruction is marked as zext_dst.\n\nThere is one notable drop in precision: whenever a BPF subprogram is\ncalled, all 64 bits of parameter registers are presumed to be used.\nThe assumption is that such a drop in precision would not inflict\na noticeable performance penalty.\n\n[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/\n[2] commit 107e16979905 (\"bpf: disable and remove registers chain based liveness\")","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":false,"headline":"bpf: Infer zext_dst based on static register liveness analysis","id":"CVE-2026-98869","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":1,"next":{"headline":"ksmbd: remove stale channels from all sessions on teardown","id":"CVE-2026-98870"},"packages":[],"prev":{"headline":"dm-pcache: reject a kset that overruns its segment","id":"CVE-2026-98868"},"products":["Linux"],"published":"2026-10-21","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-24","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-98869/"}