arch/riscv/net/bpf_jit_comp64.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
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")
Signed-off-by: Feng Jiang <jiangfeng@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>
Feng Jiang <jiangfeng@kylinos.cn> writes:
> 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")
> Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Thank you for spinning a new version!
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Björn Töpel <bjorn@kernel.org>
On Tue Jul 21, 2026 at 8:17 PM CEST, Björn Töpel wrote:
> Feng Jiang <jiangfeng@kylinos.cn> writes:
>
>> 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")
>> Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
>
> Thank you for spinning a new version!
>
> Reviewed-by: Björn Töpel <bjorn@kernel.org>
> Acked-by: Björn Töpel <bjorn@kernel.org>
There was an identical v4 resend. I applied the acks there and pushed.
Thanks.
© 2016 - 2026 Red Hat, Inc.