Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] riscv: kprobes: unsafe 32-bit read in riscv_probe_decode_insn can page fault --
commit 6f940578d2f096970e9abd6cc2894de008e29f6f Author: Xiaofeng Yuan <[email protected]> riscv: kprobes: reject probes inside LR/SC sequences This patch rejects kprobes placed inside LR/SC sequences or on the LR/SC instructions themselves to avoid livelock. It updates riscv_probe_decode_insn() to reject the instructions and adds instruction walking logic in arch_check_kprobe() to reject addresses within a sequence. [ ... ] > diff --git a/arch/riscv/kernel/probes/decode-insn.c > b/arch/riscv/kernel/probes/decode-insn.c > index 433d9035b8882..e6a8894677b10 100644 > --- a/arch/riscv/kernel/probes/decode-insn.c > +++ b/arch/riscv/kernel/probes/decode-insn.c > @@ -23,6 +23,8 @@ riscv_probe_decode_insn(probe_opcode_t *addr, struct > arch_probe_insn *api) > */ > RISCV_INSN_REJECTED(system, insn); > RISCV_INSN_REJECTED(fence, insn); > + RISCV_INSN_REJECTED(lr, insn); > + RISCV_INSN_REJECTED(sc, insn); [Severity: High] Does evaluating these macros rely on the insn variable, which is read unconditionally as a native 32-bit integer earlier in the function? arch/riscv/kernel/probes/decode-insn.c:riscv_probe_decode_insn() { probe_opcode_t insn = *addr; ... If addr is 2-byte aligned, will this native 32-bit dereference perform an unaligned memory access, potentially oopsing on RISC-V hardware that lacks kernel-mode unaligned access support? Furthermore, if addr points to a 16-bit compressed instruction at the end of a mapped page and the next page is an unmapped vmalloc guard page, could this 32-bit read cross the page boundary into unmapped memory? Would this trigger a kernel page fault and panic when tracing tools register a kprobe at such an address? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
