CVE-2026-53110

What it actually does

This is a Linux kernel defect specific to the s390/s390x BPF JIT implementation. The s390x ABI requires unsigned values to be zero-extended and signed values to be sign-extended when passed as arguments or returned from functions. The affected BPF JIT path only performed sign extension, which can cause BPF program return values and kfunc arguments to be represented incorrectly in the upper bits. In practice, this creates a mismatch between expected BPF/kernel calling semantics and generated machine code on s390x systems. Depending on the reachable BPF program type, kfunc usage, kernel configuration, and privilege model, the impact could range from incorrect BPF behavior or kernel instability to a potential local privilege-boundary issue if an attacker can load crafted BPF programs.

Why it matters to the business

The primary business risk is to organizations running Linux on IBM Z or LinuxONE s390x platforms where BPF JIT is enabled and users or workloads can load eBPF programs. Exploitation is currently assessed as low likelihood because there is no known public exploit, it is not in the CISA KEV catalog, it is not known to be used in ransomware campaigns, and the EPSS score is very low at 0.0012. However, kernel-level flaws can have high operational significance because remediation often requires kernel updates and reboots, and successful abuse could affect host integrity, workload isolation, or system stability.

How an attack unfolds

An attacker would first need local execution capability on an affected s390x Linux system and sufficient permission to load BPF programs, such as CAP_BPF, CAP_SYS_ADMIN, privileged container access, or an environment where unprivileged BPF loading is still allowed. The attacker would craft a BPF program or BPF kfunc interaction that depends on the difference between sign extension and zero extension. When the kernel JIT-compiles that BPF program for s390x, the generated code may propagate incorrect high-order bits for unsigned values. The attacker would then try to use that incorrect value handling to influence kernel-side logic, trigger memory-safety-relevant behavior, bypass an expected check, or crash the system. No mature exploitation technique is currently public, so exploitation should be treated as plausible but not confirmed without additional proof-of-concept evidence.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the s390 BPF JIT fix for zero-extending unsigned BPF program return values and kfunc arguments. Because no exact fixed package versions were provided, use the relevant distribution security advisory or kernel changelog for CVE-2026-53110 and confirm the running kernel contains the fix. Reboot into the patched kernel after installation. If immediate patching is not possible, reduce exposure by disabling unprivileged BPF loading, limiting CAP_BPF and CAP_SYS_ADMIN to trusted workloads only, avoiding privileged containers, and considering disabling the BPF JIT where operationally acceptable. Systems not using the s390/s390x architecture are not expected to be affected by this architecture-specific JIT defect.

How to confirm the fix worked

Confirm whether systems are s390x by checking architecture information such as `uname -m`; non-s390x systems should not be exposed to this specific flaw. On s390x systems, verify the active kernel version and vendor package release after reboot using `uname -r` and package-manager metadata, and confirm it maps to a vendor advisory or kernel build that contains the fix. Check BPF exposure controls such as `/proc/sys/kernel/unprivileged_bpf_disabled` and BPF-related capability assignments for services and containers. If BPF JIT is being mitigated rather than patched, verify the effective JIT setting through `/proc/sys/net/core/bpf_jit_enable` where present. For higher assurance, run vendor or upstream BPF self-tests on representative s390x systems after patching to confirm no regression in BPF behavior.

Typical attack path

1. Gain local code execution on an affected Linux s390x host or within a sufficiently privileged container.
2. Confirm the kernel allows BPF program loading through required capabilities or unprivileged BPF settings.
3. Load a crafted eBPF program that exercises unsigned return values or kfunc arguments affected by the s390x BPF JIT extension behavior.
4. Trigger the JIT-compiled BPF path repeatedly to produce incorrect value propagation in kernel context.
5. Attempt to convert the incorrect value handling into a kernel crash, policy bypass, information exposure, or privilege escalation depending on reachable kernel paths.

How to detect it

There are no reliable public indicators that uniquely identify exploitation of this issue. Detection should focus on suspicious prerequisites and post-exploitation symptoms: audit logs for BPF program loading, capability use involving CAP_BPF or CAP_SYS_ADMIN, privileged container launches, unexpected use of BPF tooling, and kernel logs showing BPF-related warnings, verifier messages, oopses, or crashes on s390x systems. Useful log sources include Linux auditd syscall telemetry for the `bpf` syscall, EDR process telemetry, container runtime logs, kernel ring buffer output from `dmesg` or journald, and package/kernel update logs. Investigate BPF program loads by unexpected users, short-lived processes that invoke BPF loaders, or BPF activity immediately preceding kernel instability. Because no threat actors or campaigns are currently reported for this vulnerability, detections should be behavioral rather than IOC-driven.

What your security team should do

• Prioritize patching s390x Linux systems that run multi-tenant workloads, container platforms, observability agents, networking programs, or any workload that can load eBPF programs.
• Inventory systems with `uname -m` equal to `s390x` and identify where BPF JIT and BPF program loading are enabled.
• Disable unprivileged BPF loading where it is not already disabled, and tightly restrict CAP_BPF, CAP_SYS_ADMIN, and privileged container use.
• Schedule kernel update and reboot windows for affected s390x hosts, giving higher priority to internet-facing, shared, or high-value platforms.
• Review audit, EDR, and container runtime telemetry for unexpected BPF program loading, especially from non-administrative users or unusual service accounts.
• Monitor vendor advisories for exact fixed kernel package versions and any change in exploit maturity, KEV status, or threat actor reporting.