All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] riscv: kprobes: fix out-of-bounds read in riscv_probe_decode_insn
Date: Wed, 11 Nov 2026 17:13:59 +0000	[thread overview]
Message-ID: <sashiko-outbox-209391@kernel.org> (raw)
In-Reply-To: <20261111-probes-in-lrsc-v2-1-b2525b7e1e8e@mobileye.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] riscv: kprobes: missing Fixes trailer for arch_prepare_kprobe()
  bug fix
--

commit 64462f82d964034abd78681cc277f651a87b8780
Author: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

> riscv: kprobes: fix out-of-bounds read in riscv_probe_decode_insn
>
> riscv_probe_decode_insn() can trigger an out-of-bounds page fault
> when probing a 16-bit compressed instruction at the end of a page.
>
> arch_prepare_kprobe() safely reads 16-bit parcels into p->opcode, but then
> passes p->addr to riscv_probe_decode_insn(), which unconditionally
> dereferences *addr as a 32-bit probe_opcode_t
>
> If a 16-bit instruction sits in the last two bytes of a mapped page next
> to an unmapped page, the 32-bit read of *addr crosses the page boundary
> and faults.
>
> Passing &p->opcode instead of p->addr to riscv_probe_decode_insn()
> (as arch_uprobe_analyze_insn() already does) avoid reading past the
> instruction.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/bug/linux-812af091-20d1-4915-97a6-741f51e07022
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

[Severity: Low]
Should this bug fix include a Fixes tag for the commit that introduced
the unguarded p->addr dereference in arch_prepare_kprobe()?

  Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-probes-in-lrsc-v2-0-b2525b7e1e8e@mobileye.com?part=1

  reply	other threads:[~2026-11-11 17:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 17:01 [PATCH v2 0/2] riscv: probes: reject probes inside an LR/SC sequence Vladimir Kondratiev
2026-11-11 17:01 ` Vladimir Kondratiev
2026-11-11 17:01 ` [PATCH v2 1/2] riscv: kprobes: fix out-of-bounds read in riscv_probe_decode_insn Vladimir Kondratiev
2026-11-11 17:01   ` Vladimir Kondratiev
2026-11-11 17:13   ` sashiko-bot [this message]
2026-11-11 17:01 ` [PATCH v2 2/2] riscv: probes: reject probes inside an LR/SC sequence Vladimir Kondratiev
2026-11-11 17:01   ` Vladimir Kondratiev
2026-11-11 17:21   ` sashiko-bot
2026-11-12  7:54   ` Nam Cao
2026-11-12  7:54     ` Nam Cao
2026-11-12 11:19     ` Vladimir Kondratiev
2026-11-12 11:19       ` Vladimir Kondratiev

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-209391@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vladimir.kondratiev@mobileye.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.