Answer in brief
CVE-2026-89906 records a Unknown severity vulnerability in LoongArch: BPF: Refactor jump offset calculation in tail call. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 <882b8912b7e92341fdb115ba0e2e5142a28684ff || >=cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 <96f44d493c280ea161569c43d7ed0f3b0815803a || >=cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 <37d545d12f21c4d50612ecaebd7ae1e5bf91b2d8 || 1a782fa32e644aa9fbae6c8488f3e61221ac96e1 || 17c010fe45def335fe03a0718935416b04c7f349 || f83d469e16bb1f75991ca67c56786fb2aaa42bea || f2b5e50cc04d7a049b385bc1c93b9cbf5f10c94f || 9262e3e04621558e875eb5afb5e726b648cd5949 || >=6.1.149 <6.2 || >=6.6.103 <6.7 || >=6.12.43 <6.13 || >=6.15.11 <6.16 || >=6.16.2 <6.17 | 882b8912b7e92341fdb115ba0e2e5142a28684ff, 96f44d493c280ea161569c43d7ed0f3b0815803a, 37d545d12f21c4d50612ecaebd7ae1e5bf91b2d8, 6.2, 6.7, 6.13, 6.16, 6.17 |
| Linux/Linuxgeneric | 6.17 | Not reported |
Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 16, 2026
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Refactor jump offset calculation in tail call The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: "ctx->offset[insn + 1] - ctx->idx". To avoid a false 16-bit range check abort during size estimation, add a "ctx->image == NULL" guard to inject a safe dummy offset.
Quoted source text, attributed separately from HOL analysis.