From: sashiko-bot@kernel.org
To: "Xiaofeng Yuan" <yuanxiaofeng@eswincomputing.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/2] riscv: kprobes: reject probes inside LR/SC sequences
Date: Fri, 16 Oct 2026 08:29:42 +0000 [thread overview]
Message-ID: <sashiko-outbox-174019@kernel.org> (raw)
In-Reply-To: <20261016081706.1085-2-yuanxiaofeng@eswincomputing.com>
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 <yuanxiaofeng@eswincomputing.com>
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/20261016081706.1085-1-yuanxiaofeng@eswincomputing.com?part=1
next prev parent reply other threads:[~2026-10-16 8:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 8:17 [PATCH v6 0/2] riscv: kprobes: reject probes inside LR/SC sequences Xiaofeng Yuan
2026-10-16 8:17 ` Xiaofeng Yuan
2026-10-16 8:17 ` [PATCH v6 1/2] " Xiaofeng Yuan
2026-10-16 8:17 ` Xiaofeng Yuan
2026-10-16 8:29 ` sashiko-bot [this message]
2026-10-16 10:13 ` Nam Cao
2026-10-16 10:13 ` Nam Cao
2026-10-16 8:17 ` [PATCH v6 2/2] riscv: kprobes: add KUnit test for LR/SC sequence rejection Xiaofeng Yuan
2026-10-16 8:17 ` Xiaofeng Yuan
2026-10-16 10:42 ` Nam Cao
2026-10-16 10:42 ` Nam Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-174019@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yuanxiaofeng@eswincomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.