{
  "cveId": "CVE-2026-99092",
  "url": "https://patchblox.com/security/cve/CVE-2026-99092",
  "summary": "CVE-2026-99092 is fixed in linux on 1 platform, first by DEBIAN-CVE-2026-99092, released October 27, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  riscv: patch: fix handling of bpf-jit execmem ad...",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  riscv: patch: fix handling of bpf-jit execmem addresses  Commit 8718e5a3090b (\u0022riscv: patch: skip fixmap mapping when kernel text is already writable\u0022) gated the core_kernel_text() branch of patch_map() on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem.  That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIG_STRICT_MODULE_RWX says.  With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed.  Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 (\u0022riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX\u0022). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(), which arch code cannot influence. The only place this can be handled is patch_map().  This is the same problem that was fixed on arm64 by commit b1480ed230ac (\u0022arm64: patching: fix handling of execmem addresses\u0022), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select it.  Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y as well, and the bug is reachable in that configuration too.  The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map().",
  "published": "2026-10-26T15:16:48Z",
  "severity": "",
  "epss": 0.00164,
  "epssPercentile": 0.05633,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.12.115-2",
      "fix": "DEBIAN-CVE-2026-99092",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-99092",
      "released": "2026-10-27T21:14:52Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.11-1",
      "fix": "DEBIAN-CVE-2026-99092",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-99092",
      "released": "2026-10-27T21:14:52Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T06:59:42Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}