Cloudanix VulnDB

CVE-2026-68295

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A math-handling mistake in low-level code on certain processors can let attackers trick security checks inside the operating system kernel.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The LoongArch BPF JIT sign-extends the 32-bit result of signed ALU32 BPF_DIV and BPF_MOD operations instead of zero-extending it, leaving bits 63:32 set for negative quotients or remainders while the verifier and interpreter treat those bits as zero, violating eBPF register state assumptions.

Why it matters to the business

Organizations running Linux on LoongArch hardware that rely on eBPF for networking, security, or observability face risk of incorrect program results, potential sandbox escapes, or kernel instability until systems are updated.

How an attack unfolds

An attacker with local access loads a crafted eBPF program containing signed 32-bit division or modulo operations that yield negative results. The vulnerable JIT emits code that produces non-zero upper bits, creating a register state mismatch that can be chained with other primitives to corrupt memory or bypass verifier checks.

How to fix it

Apply the upstream kernel patch that preserves sign-extension on operands but zero-extends the ALU32 result after signed div/mod instructions in the LoongArch BPF JIT; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the fix by inspecting arch/loongarch/net/bpf_jit.c (or equivalent) for the post-divide zero-extension logic on signed ALU32 paths and test that JIT and interpreter produce identical results for negative 32-bit quotients.

Typical attack path

  1. Obtain local unprivileged or privileged access on a LoongArch Linux system
  2. Craft and submit an eBPF program via the bpf() syscall that exercises signed ALU32 div/mod
  3. Trigger JIT compilation and execution of the program
  4. Leverage the resulting register mismatch to escape eBPF sandbox or escalate privileges

How to detect it

Review kernel audit logs and bpftrace or perf output for unusual eBPF program loads containing div or mod opcodes; compare JIT-generated code against interpreter results for programs using signed 32-bit arithmetic.

What your security team should do

  • Prioritize kernel updates on all LoongArch production systems within standard change windows
  • Temporarily disable unprivileged BPF loading via sysctl kernel.unprivileged_bpf_disabled=1 where feasible
  • Audit loaded BPF programs for ALU32 div/mod usage on affected architectures
  • Monitor EPSS and KEV status for any future increase in exploit activity

The record

In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Zero-extend signed ALU32 div/mod results ALU32 operations write a 32-bit result and leave the upper 32 bits of the BPF register zero. The LoongArch JIT sign-extends the result of signed ALU32 BPF_DIV and BPF_MOD (off=1), so a negative 32-bit quotient or remainder leaves bits 63:32 set in JITted code while the verifier and interpreter model those bits as zero. Keep sign-extension on the operands, which signed divide needs, and zero-extend the ALU32 result after the divide or modulo instruction, matching the unsigned ALU32 div/mod paths and every other ALU32 operation in this JIT.

Affected packages

Ecosystem Package Introduced Fixed