← Back to Blog
RISC-V Datacenter

CVE-2026-92518: RISC-V BPF Tailcall With Clang CFI Corrupts Kernel Stack (CVSS 7.8)

2026-09-21 4 min read EN
RISC-V Linux kernel CVE BPF CFI Clang tailcall security kernel hardening KCFI

Table of Contents

Published: 2026-09-21 · Category: RISC-V Datacenter · Reading time: ~4 min · Status: DRAFT

The record

CVE-2026-92518, CNA kernel.org, was published 17 September 2026 and updated 18 September 2026. Title: "riscv, bpf: Fix kernel stack corruption in tailcall with CFI".

Severity is 7.8 HIGH under CVSS 3.1, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — local attack vector, low complexity, low privileges required, no user interaction, with high impact on confidentiality, integrity and availability.

Root cause, in the maintainer's own words

The description is unusually precise, so it is worth quoting rather than paraphrasing:

When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption.

Read that as an off-by-four. On RISC-V under Clang's Kernel Control Flow Integrity, the BPF program entry pointer is already adjusted past the kcfi instruction. The tailcall path adds that adjustment a second time. The jump therefore lands four bytes too far and skips the instruction that adjusts the stack pointer. Everything after that runs against a corrupted stack.

The consequence is named in the description: kernel stack corruption.

Who is actually exposed

Three conditions must hold simultaneously, which usefully narrows the blast radius:

  1. RISC-V kernel build (this is an architecture-specific defect in the RV64 BPF JIT)
  2. CONFIG_CFI_CLANG enabled
  3. BPF tailcalls in use, reachable by an attacker with local low-privilege code execution

Per the CVE record, the affected range begins at 6.12. Versions recorded as unaffected are:

The record also lists a set of pre-6.12 commit-range entries and three stable-tree commit references, so downstream backports exist. If you run a vendor kernel, match against your vendor's advisory rather than assuming the upstream numbering maps cleanly.

Why this is a datacenter story, not an embedded one

Clang CFI on RISC-V is a hardening configuration. It is the kind of option you switch on for internet-facing or multi-tenant hosts, and it pairs with BPF-heavy observability, networking and security tooling — exactly the stack a RISC-V server runs.

The uncomfortable irony is worth stating plainly: a control-flow-integrity feature is what triggers the bug. Turning on CFI does not merely fail to protect you here; under the specific tailcall path it actively introduces the corruption. That is an argument for testing hardening configurations as a distinct matrix, not for concluding that hardening is a bad idea.

RISC-V's own CFI consists of two independent extensions — Zicfilp (landing pads, for forward-edge) and Zicfiss (shadow stack, for backward-edge) — which is the hardware substrate this software CFI story sits alongside. That pairing is reported in secondary coverage; the CVE text itself only refers to Clang CFI.

A sibling fix landed in the same window

CVE-2026-90195 was updated 17 September 2026: "riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args".

On RV64 the ABI requires sign-extension for signed 1-byte and 2-byte kfunc arguments, and the RV64 JIT did not perform it. A prior commit had masked the issue by making arguments appear correctly extended; after that commit's removal the problem surfaced and failed the kfunc_call/kfunc_call_test4 selftests. That record lists the same unaffected boundaries: 6.12.110, 6.18.52, 7.2.6, 7.3-rc1.

Two RISC-V BPF correctness fixes in the same week is a reasonable signal about where the maturation pressure is.

What to do

  1. Check CONFIG_CFI_CLANG on every RISC-V kernel you build. If it is off, this specific bug does not fire.
  2. Move to a fixed tree — 6.18.52+, 7.2.6+, or 7.3-rc1 or later — or take the stable commits listed in the CVE record.
  3. Audit BPF tailcall usage. Workloads using tailcalls are the reachable path.
  4. Do not assume your vendor's version numbering matches upstream. Read the vendor advisory.

Not disclosed / not established

Sources

Verification notes

Open RISC-V — RISC-V Silicon & Development Board Store — open-riscv.com