Cloudanix VulnDB

CVE-2026-98869

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 21, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's network safety checker on IBM mainframe hardware can let a logged-in user bypass checks and take over the whole computer.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The BPF verifier's static liveness analysis for 32-bit subregisters is incomplete after removal of REG_LIVE_READ propagation; on s390 this causes missing explicit zero-extension (zext_dst) instructions before operations such as w1 += 1, allowing an attacker-controlled 64-bit value to retain arbitrary data in the upper 32 bits.

Why it matters to the business

On s390 Linux systems, a local user with the ability to load BPF programs can achieve arbitrary kernel memory reads or writes, resulting in full host compromise and potential lateral movement or data exfiltration.

How an attack unfolds

An attacker loads a carefully constructed BPF program containing 32-bit operations whose upper-half liveness differs across verification paths. The flawed bpf_compute_live_registers pass fails to mark the instruction for zero-extension; the JIT therefore emits code that leaves attacker-controlled data in the upper 32 bits, which is later used for pointer arithmetic or memory access.

How to fix it

Upgrade the Linux kernel to a version containing the commit that replaces subreg_def tracking with bpf_compute_live_registers liveness analysis for zext_dst decisions. Reboot affected s390 systems after the update. Until patches are available, restrict unprivileged BPF loading via sysctl kernel.unprivileged_bpf_disabled=1.

How to confirm the fix worked

Confirm the presence of the upstream fix by checking that bpf_opt_subreg_zext_lo32_rnd_hi32 and propagate_liveness no longer rely on subreg_def; run the BPF selftests for s390 and verify that programs using 32-bit operations produce identical results with and without the verifier's previous liveness logic.

Typical attack path

  1. Obtain CAP_BPF or root on an s390 Linux system
  2. Craft and load a BPF program that exercises 32-bit ALU operations with divergent upper-half liveness across verifier paths
  3. Trigger the missing zext_dst insertion during verification
  4. Execute the resulting JIT-compiled program to read or write kernel memory via the uninitialized register bits
  5. Escalate to full kernel control

How to detect it

Search kernel audit logs and BPF verifier traces for programs that trigger repeated verification of 32-bit ALU operations on s390; look for unusual JIT output containing missing zero-extension sequences around w-register operations. Correlate with process creation of bpftool or custom loaders.

What your security team should do

  • Prioritize kernel updates on all s390 production systems within the next maintenance window
  • Audit any workloads that load custom BPF programs and apply least-privilege restrictions
  • Monitor vendor advisories for the exact fixed kernel versions once released

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows: - bpf_reg_state->subreg_def field was set by do_check_insn() for each operation defining lower but not the upper halves of the register. - Whenever an operation reading the whole register was verified, the verifier checked register's subreg_def and set bpf_insn_aux_data->zext_dst flag as true via a call to mark_insn_zext() function. - After the verification was complete, a special pass bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations with bpf_insn_aux_data->zext_dst set as true by adding explicit zero extension. Note that the logic above relies on bpf_reg_state->subreg_def, which is a property of a current verifier state. Before the commit [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as flags REG_LIVE_READ{32,64} in bpf_reg_state->live. - The function propagate_liveness() called mark_insn_zext() in order to transfer the knowledge about which registers have their upper halves alive (and thus might require zero extension). The commit [2] removed the two steps described above, hence making possible a situation like below: - The register's upper half is set and is used on some verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created while processing some instruction between register initialization and usage. - On some other verification path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In such a case the register's initialization on path P2 would lack zext_dst mark, making it possible for the program to inject an arbitrary value in the register's upper half. This commit replaces subreg_def based logic with computing zext_dst statically, as a part of the bpf_compute_live_registers() analysis: - The analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction defines a 32-bit subregister, but not the whole register, *and* the upper half of the register is alive after that instruction, the instruction is marked as zext_dst. There is one notable drop in precision: whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The assumption is that such a drop in precision would not inflict a noticeable performance penalty. [1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")

Affected packages

Ecosystem Package Introduced Fixed