[PATCH v4] bpf, riscv: fix extable handling for arena load_acquire

[PATCH v4] bpf, riscv: fix extable handling for arena load_acquire

[Feng Jiang]

emit_atomic_ld_st() returns 1 to have build_body() skip the zext after
a sub-word load_acquire. The caller does "ret = ret ?:
add_exception_handler(...)", which skips add_exception_handler() on any
non-zero ret, so the extable entry is missing and a faulting
PROBE_ATOMIC load_acquire oopses.

REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still
thinks the load overwrote it, so a program can leak it through a map.

Check ret >= 0 before calling add_exception_handler(), and pass rd for
LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret
unchanged for the zext skip.

Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64")
Suggested-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
---
Changes in v4:
- No code changes (pure v3 re-send).
- Restore Suggested-by for Pu Lehui (from v2, missed in v3).
- Restore Reviewed-by from Pu Lehui (v2)
- Link to v3: https://lore.kernel.org/r/20260720-bpf-riscv-fix-extable-v3-1-e9a603882309@kylinos.cn

Changes in v3:
- Pass rd to add_exception_handler() for LOAD_ACQ so the destination is
  zeroed on fault instead of REG_DONT_CLEAR_MARKER (Björn Töpel).
- Link to v2: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v2-1-421f75812533@kylinos.cn

Changes in v2:
- Drop extra variable as suggested by Pu Lehui.
- Link to v1: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v1-1-af023cc17af4@kylinos.cn
---
 arch/riscv/net/bpf_jit_comp64.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index f9d5347ba966..e1519ab4356c 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -1986,7 +1986,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		else
 			ret = emit_atomic_rmw(rd, rs, insn, ctx);
 
-		ret = ret ?: add_exception_handler(insn, REG_DONT_CLEAR_MARKER, ctx);
+		/* ret can be 1 (skip-zext); extable entry still needs to be added */
+		if (ret >= 0)
+			ret = add_exception_handler(insn,
+				insn->imm == BPF_LOAD_ACQ ? rd : REG_DONT_CLEAR_MARKER,
+				ctx) ?: ret;
+
 		if (ret)
 			return ret;
 		break;

---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260716-bpf-riscv-fix-extable-399947ca778d

Best regards,
-- 
Feng Jiang <jiangfeng@kylinos.cn>

[PATCH v4] bpf, riscv: fix extable handling for arena load_acquire

[Feng Jiang]

emit_atomic_ld_st() returns 1 to have build_body() skip the zext after
a sub-word load_acquire. The caller does "ret = ret ?:
add_exception_handler(...)", which skips add_exception_handler() on any
non-zero ret, so the extable entry is missing and a faulting
PROBE_ATOMIC load_acquire oopses.

REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still
thinks the load overwrote it, so a program can leak it through a map.

Check ret >= 0 before calling add_exception_handler(), and pass rd for
LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret
unchanged for the zext skip.

Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64")
Suggested-by: Pu Lehui <pulehui@huawei.com>
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
---
Changes in v4:
- No code changes (pure v3 re-send).
- Restore Suggested-by for Pu Lehui (from v2, missed in v3).
- Restore Reviewed-by from Pu Lehui (v2)
- Link to v3: https://lore.kernel.org/r/20260720-bpf-riscv-fix-extable-v3-1-e9a603882309@kylinos.cn

Changes in v3:
- Pass rd to add_exception_handler() for LOAD_ACQ so the destination is
  zeroed on fault instead of REG_DONT_CLEAR_MARKER (Björn Töpel).
- Link to v2: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v2-1-421f75812533@kylinos.cn

Changes in v2:
- Drop extra variable as suggested by Pu Lehui.
- Link to v1: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v1-1-af023cc17af4@kylinos.cn
---
 arch/riscv/net/bpf_jit_comp64.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index f9d5347ba966..e1519ab4356c 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -1986,7 +1986,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		else
 			ret = emit_atomic_rmw(rd, rs, insn, ctx);
 
-		ret = ret ?: add_exception_handler(insn, REG_DONT_CLEAR_MARKER, ctx);
+		/* ret can be 1 (skip-zext); extable entry still needs to be added */
+		if (ret >= 0)
+			ret = add_exception_handler(insn,
+				insn->imm == BPF_LOAD_ACQ ? rd : REG_DONT_CLEAR_MARKER,
+				ctx) ?: ret;
+
 		if (ret)
 			return ret;
 		break;

---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260716-bpf-riscv-fix-extable-399947ca778d

Best regards,
-- 
Feng Jiang <jiangfeng@kylinos.cn>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v4] bpf, riscv: fix extable handling for arena load_acquire

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The x86 BPF JIT incorrectly handles BPF_LOAD_ACQ instructions in its exception table population logic, leaving the destination register uncleared on an arena fault and checking the wrong register for arena violations.
--

--- Patch [1]: [PATCH v4] bpf, riscv: fix extable handling for arena load_acquire ---
commit 2540096dc96b56cd6aa635099890caa90920e4b4
Author: Feng Jiang <jiangfeng@kylinos.cn>

bpf, riscv: fix extable handling for arena load_acquire

This commit fixes the exception table handling for arena load_acquire
instructions in the RISC-V BPF JIT. It ensures that the destination register
is cleared on a fault to prevent verifier bypasses and pointer leaks.

Link: https://lore.kernel.org/r/20260720-bpf-riscv-fix-extable-v3-1-e9a603882309@kylinos.cn
Link: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v2-1-421f75812533@kylinos.cn
Link: https://lore.kernel.org/r/20260716-bpf-riscv-fix-extable-v1-1-af023cc17af4@kylinos.cn

> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
> index f9d5347ba966b..e1519ab4356c1 100644
> --- a/arch/riscv/net/bpf_jit_comp64.c
> +++ b/arch/riscv/net/bpf_jit_comp64.c
> @@ -1986,7 +1986,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  		else
>  			ret = emit_atomic_rmw(rd, rs, insn, ctx);
>  
> -		ret = ret ?: add_exception_handler(insn, REG_DONT_CLEAR_MARKER, ctx);
> +		/* ret can be 1 (skip-zext); extable entry still needs to be added */
> +		if (ret >= 0)
> +			ret = add_exception_handler(insn,
> +				insn->imm == BPF_LOAD_ACQ ? rd : REG_DONT_CLEAR_MARKER,
> +				ctx) ?: ret;
> +

[Severity: High]
This is a pre-existing issue, but does the x86 BPF JIT have the exact same
bug that needs fixing?

Looking at do_jit() in arch/x86/net/bpf_jit_comp.c:

				if (BPF_CLASS(insn->code) == BPF_LDX) {
					arena_reg = reg2pt_regs[src_reg];
					fixup_reg = reg2pt_regs[dst_reg];
				} else {
					arena_reg = reg2pt_regs[dst_reg];
					fixup_reg = DONT_CLEAR;
				}

Since BPF_LOAD_ACQ is encoded with the BPF_STX class, it falls into the else
branch, setting fixup_reg to DONT_CLEAR.

If a BPF program executes a BPF_LOAD_ACQ with an invalid pointer into the
arena memory, causing a page fault, does this leave the destination register
un-zeroed?

Could this bypass the verifier's assumption that it was overwritten by a safe
scalar, potentially leaking kernel pointers out to userspace?

>  		if (ret)
>  			return ret;
>  		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-bpf-riscv-fix-extable-v4-1-165c0b3b07d5@kylinos.cn?part=1