{"api_version":"1","generated_at":"2026-10-24T05:58:32+00:00","cve":"CVE-2026-98869","urls":{"html":"https://cve.report/CVE-2026-98869","api":"https://cve.report/api/cve/CVE-2026-98869.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98869","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98869"},"summary":{"title":"bpf: Infer zext_dst based on static register liveness analysis","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->subreg_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->zext_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->zext_dst set as true by adding\n  explicit zero extension.\n\nNote that the logic above relies on bpf_reg_state->subreg_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->live.\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\")","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-21 15:17:19","updated_at":"2026-10-21 15:17:19"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/7ce090afbf725e25fff29caacce1eaf8459b1117","name":"https://git.kernel.org/stable/c/7ce090afbf725e25fff29caacce1eaf8459b1117","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98869","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98869","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 107e169799057bc6a379ddb625cbe1e51cfc7d72 7ce090afbf725e25fff29caacce1eaf8459b1117 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.18","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["include/linux/bpf_verifier.h","kernel/bpf/fixups.c","kernel/bpf/liveness.c","kernel/bpf/verifier.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"7ce090afbf725e25fff29caacce1eaf8459b1117","status":"affected","version":"107e169799057bc6a379ddb625cbe1e51cfc7d72","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["include/linux/bpf_verifier.h","kernel/bpf/fixups.c","kernel/bpf/liveness.c","kernel/bpf/verifier.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.18"},{"lessThan":"6.18","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"6.18","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->subreg_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->zext_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->zext_dst set as true by adding\n  explicit zero extension.\n\nNote that the logic above relies on bpf_reg_state->subreg_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->live.\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\")"}],"providerMetadata":{"dateUpdated":"2026-10-21T14:55:10.364Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/7ce090afbf725e25fff29caacce1eaf8459b1117"}],"title":"bpf: Infer zext_dst based on static register liveness analysis","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98869","datePublished":"2026-10-21T14:55:10.364Z","dateReserved":"2026-09-25T10:25:14.377Z","dateUpdated":"2026-10-21T14:55:10.364Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-21 15:17:19","lastModifiedDate":"2026-10-21 15:17:19","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98869","Ordinal":"1","Title":"bpf: Infer zext_dst based on static register liveness analysis","CVE":"CVE-2026-98869","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98869","Ordinal":"1","NoteData":"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->subreg_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->zext_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->zext_dst set as true by adding\n  explicit zero extension.\n\nNote that the logic above relies on bpf_reg_state->subreg_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->live.\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\")","Type":"Description","Title":"bpf: Infer zext_dst based on static register liveness analysis"}]}}}