CVE-2026-99092: riscv: patch: fix handling of bpf-jit execmem addresses

In the Linux kernel, the following vulnerability has been resolved:

riscv: patch: fix handling of bpf-jit execmem addresses

Commit 8718e5a3090b ("riscv: patch: skip fixmap mapping when kernel text is already writable") gated the corekerneltext() branch of patchmap() on CONFIGSTRICTKERNELRWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem.

That branch only creates a temporary writable fixmap alias when CONFIGSTRICTMODULERWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpfprogpackalloc calls setmemoryrox() on every pack unconditionally in allocnewpack(), independently of any CONFIGSTRICTRWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIGSTRICTMODULERWX says.

With CONFIGSTRICTMODULERWX=n, patchmap() returns the read-only address directly, the subsequent copytokernelnofault() takes a page fault and returns -EFAULT. bpfarchtextcopy() turns that into -EINVAL, which propagates through bpfjitbinarypackfinalize() to the WARNON() in bpfintjitcompile() and leaves the program un-JITed.

Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 ("riscv: mm: make EXECMEMKPROBES writable without CONFIGSTRICTMODULERWX"). EXECMEMBPF is already PAGEKERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in allocnewpack(), which arch code cannot influence. The only place this can be handled is patchmap().

This is the same problem that was fixed on arm64 by commit b1480ed230ac ("arm64: patching: fix handling of execmem addresses"), and the fix is the same: CONFIGEXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIGBPFJIT, CONFIGKPROBES and CONFIGMODULES all select it.

Note that this is not limited to CONFIGMODULES=n. Unlike arm64, riscv selects CONFIGARCHOPTIONALKERNELRWX, so CONFIGSTRICTMODULERWX can be disabled with CONFIGMODULES=y as well, and the bug is reachable in that configuration too.

The !CONFIGMMU build is unaffected: it has its own patchinsnset() and patchinsnwrite() implementations and never calls patchmap().