CVE-2026-98869

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-98869", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-09-25T10:25:14.377Z", "datePublished": "2026-10-21T14:55:10.364Z", "dateUpdated": "2026-10-24T14:09:25.680Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-10-24T14:09:25.680Z"}, "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\")"}], "metrics": [{"cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH"}, "scenarios": [{"lang": "en", "value": "AV:L - Crafted bytecode enters through bpf(BPF_PROG_LOAD) \u2192 bpf_prog_load() \u2192 bpf_check() \u2192 patched bpf_compute_live_registers(); no network protocol supplies it, and the socket filter is locally loaded and attached.\nAC:L - bpf_is_state_visited() checkpoints attacker-supplied control flow, letting one path fully define R6 and a pruned path execute W6=32 before a 64-bit use; the attacker controls both paths and the retained high bits, with no race or external timing.\nPR:L - bpf_prog_load() permits BPF_PROG_TYPE_SOCKET_FILTER without CAP_BPF when sysctl_unprivileged_bpf_disabled is 0; exploitation was reproduced as uid 1000 with empty capability sets, and BPF tokens separately support namespaced CAP_BPF delegation.\nUI:N - The attacker loads the program, attaches it to an owned socket through SO_ATTACH_BPF, and supplies traffic to execute it; no action by another user is required.\nS:U - The bpf verifier and s390 JIT fault, ARRAY-map out-of-bounds accesses, and resulting current-process credential modification all remain within the host kernel's security authority; no VM or IOMMU boundary is crossed.\nC:H - The missing zext_dst lets attacker-controlled upper bits form an unchecked 64-bit offset from an ARRAY map-value pointer; the demonstrated exploit disclosed map->ops, derived the KASLR slide, and obtained arbitrary kernel reads.\nI:H - The same unchecked ARRAY map-value offset provides arbitrary kernel writes; the demonstrated exploit located and modified the calling process's credentials to obtain uid 0.\nA:H - The arbitrary kernel-write primitive created by the omitted s390 zero-extension can corrupt kernel objects or control-flow data, causing an oops or system crash in addition to privilege escalation."}]}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/bpf_verifier.h", "kernel/bpf/fixups.c", "kernel/bpf/liveness.c", "kernel/bpf/verifier.c"], "versions": [{"version": "107e169799057bc6a379ddb625cbe1e51cfc7d72", "lessThan": "7ce090afbf725e25fff29caacce1eaf8459b1117", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/bpf_verifier.h", "kernel/bpf/fixups.c", "kernel/bpf/liveness.c", "kernel/bpf/verifier.c"], "versions": [{"version": "6.18", "status": "affected"}, {"version": "0", "lessThan": "6.18", "status": "unaffected", "versionType": "semver"}, {"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.18", "versionEndExcluding": "7.3"}]}]}], "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"}}}}

{}

{"affected": [{"affectedData": [{"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"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "cveTags": [], "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\")"}], "id": "CVE-2026-98869", "lastModified": "2026-10-24T14:16:47.630", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary"}]}, "published": "2026-10-21T15:17:19.827", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/7ce090afbf725e25fff29caacce1eaf8459b1117"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

{"bugzilla": {"description": "kernel: bpf: Infer zext_dst based on static register liveness analysis", "id": "2558313", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2558313"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.8", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "draft"}, "cwe": "CWE-681", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbpf: Infer zext_dst based on static register liveness analysis\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.\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.\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- bpf_reg_state->subreg_def field was set by do_check_insn()\nfor each operation defining lower but not the upper halves\nof the register.\n- Whenever an operation reading the whole register was verified,\nthe verifier checked register's subreg_def and set\nbpf_insn_aux_data->zext_dst flag as true via a call to\nmark_insn_zext() function.\n- After the verification was complete, a special pass\nbpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations\nwith bpf_insn_aux_data->zext_dst set as true by adding\nexplicit zero extension.\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- The verifier tracked upper and lower register halves' liveness as\nflags REG_LIVE_READ{32,64} in bpf_reg_state->live.\n- The function propagate_liveness() called mark_insn_zext()\nin order to transfer the knowledge about which registers have\ntheir upper halves alive (and thus might require zero extension).\nThe commit [2] removed the two steps described above,\nhence making possible a situation like below:\n- The register's upper half is set and is used on some verification\npath P1 and the register happens not to be marked as precise.\n- The checkpoint C is created while processing some instruction\nbetween register initialization and usage.\n- On some other verification path P2 the register's upper half is not\ninitialized and that path ends hitting the checkpoint C.\n- In such a case the register's initialization on path P2 would lack\nzext_dst mark, making it possible for the program to inject\nan arbitrary value in the register's upper half.\nThis commit replaces subreg_def based logic with computing zext_dst\nstatically, as a part of the bpf_compute_live_registers() analysis:\n- The analysis now tracks usage of upper and lower halves of the\nregisters separately.\n- If some instruction defines a 32-bit subregister, but not the whole\nregister, *and* the upper half of the register is alive after that\ninstruction, the instruction is marked as zext_dst.\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[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\")", "A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) verifier. A local attacker could achieve privilege escalation by loading a specially crafted BPF program into the kernel. The vulnerability occurs because the verifier fails to properly track register states across execution paths during 32-bit operations, leading to missing zero-extension instructions. Consequently, an attacker can inject arbitrary values into 64-bit registers to bypass kernel safety checks and compromise system memory."], "name": "CVE-2026-98869", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/a:redhat:openshift:4", "fix_state": "Not affected", "package_name": "openshift/ose-rhel-coreos-8", "product_name": "Red Hat OpenShift Container Platform 4"}, {"cpe": "cpe:/a:redhat:openshift:4", "fix_state": "Not affected", "package_name": "openshift/ose-rhel-coreos-9", "product_name": "Red Hat OpenShift Container Platform 4"}], "public_date": "2026-10-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-98869\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-98869\nhttps://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98869.mbox"], "threat_severity": "Important"}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[107e169799057bc6a379ddb625cbe1e51cfc7d72,7ce090afbf725e25fff29caacce1eaf8459b1117)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "generic", "value": "6.18"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[0,6.18)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[7.3,*]"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[107e169799057bc6a379ddb625cbe1e51cfc7d72,7ce090afbf725e25fff29caacce1eaf8459b1117)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "generic", "value": "6.18"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[0,6.18)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[7.3,*]"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}], "created": "2026-10-21T22:45:14.293690+00:00", "updated": "2026-10-24T15:45:07.123859+00:00", "vendors": ["linux", "linux$PRODUCT$linux", "linux$PRODUCT$linux_kernel"]}