From: sashiko-bot@kernel.org
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] kprobes: Add KUnit test cases for kprobes regressions
Date: Tue, 10 Nov 2026 01:40:30 +0000 [thread overview]
Message-ID: <sashiko-outbox-205975@kernel.org> (raw)
In-Reply-To: <179427362063.291326.12590758885048682193.stgit@devnote2>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] kprobes: test_optprobe_rearm_unoptimizing() misses jump
overwrite on re-arm
--
commit d9ce37575f42c89c2d4a066b90a06cb4ee50df98
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
kprobes: Add KUnit test cases for kprobes regressions
This commit adds four KUnit test cases to lib/tests/test_kprobes.c covering
regressions in kprobes registration, ftrace ops switching, and optimization
state transitions.
> diff --git a/lib/tests/test_kprobes.c b/lib/tests/test_kprobes.c
> index 06e729e4de051..d692612bc2245 100644
> --- a/lib/tests/test_kprobes.c
> +++ b/lib/tests/test_kprobes.c
[ ... ]
> +/* Test for: kprobes: Do not overwrite jump instruction when re-arming unoptimizing probe */
> +static void test_optprobe_rearm_unoptimizing(struct kunit *test)
> +{
> + struct kprobe opt_kp = {
> + .symbol_name = "kprobe_opt_target",
> + .pre_handler = kp_pre_handler,
> + };
> +
> + current_test = test;
> + KUNIT_ASSERT_EQ(test, 0, register_kprobe(&opt_kp));
> +
> + /* Allow background optimizer thread to jump-optimize the probe */
> + wait_for_kprobe_optimizer();
> +
> + /* Temporarily disable probe (queues on unoptimizing_list, leaves jump) */
> + KUNIT_EXPECT_EQ(test, 0, disable_kprobe(&opt_kp));
> +
> + /* Immediately re-enable (re-arm) before optimizer thread unoptimizes */
> + KUNIT_EXPECT_EQ(test, 0, enable_kprobe(&opt_kp));
> +
> + /* Verify jump opcode was not corrupted by an unaligned INT3 overwrite */
> + preh_val = 0;
> + opt_target(rand1);
> + KUNIT_EXPECT_NE(test, 0, preh_val);
> +
> + unregister_kprobe(&opt_kp);
> +}
> +#endif
[Severity: Medium]
Does test_optprobe_rearm_unoptimizing() pass even when enable_kprobe()
overwrites the jump instruction at opt_kp.addr with a breakpoint?
When disable_kprobe() runs on the optimized probe, __disarm_kprobe() queues
it on unoptimizing_list and skips arch_disarm_kprobe(), leaving the jump in
place. However, enable_kprobe() calls __arm_kprobe(), which unconditionally
calls arch_arm_kprobe() before optimize_kprobe():
kernel/kprobes.c:__arm_kprobe() {
...
arch_arm_kprobe(p);
optimize_kprobe(p); /* Try to optimize (add kprobe to a list) */
}
arch_arm_kprobe() overwrites the jump opcode at p->addr with a breakpoint,
while optimize_kprobe() sees KPROBE_FLAG_OPTIMIZED and
optprobe_queued_unopt(op), dequeues the probe from unoptimizing_list, and
returns early without re-optimizing it. This leaves the probe permanently
de-optimized with a breakpoint at p->addr while KPROBE_FLAG_OPTIMIZED
remains set. Because hitting that breakpoint still invokes kp_pre_handler(),
checking only that preh_val is non-zero does not detect that the jump opcode
was overwritten.
--
Sashiko AI review · https://sashiko.dev/#/patchset/179427358690.291326.2078291446658598883.stgit@devnote2?part=4
next prev parent reply other threads:[~2026-11-10 1:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 1:19 [PATCH v2 0/4] kprobes: Fixes for ftrace ops and optprobe state machine Masami Hiramatsu (Google)
2026-11-10 1:19 ` [PATCH v2 1/4] kprobes: Switch ftrace ops when adding probe with post_handler Masami Hiramatsu (Google)
2026-11-10 1:20 ` [PATCH v2 2/4] kprobes: Fix UAF and queue cooling probes on forced unoptimization Masami Hiramatsu (Google)
2026-11-10 1:20 ` [PATCH v2 3/4] kprobes: Re-optimize blocked sibling probe when cooling finishes Masami Hiramatsu (Google)
2026-11-10 1:20 ` [PATCH v2 4/4] kprobes: Add KUnit test cases for kprobes regressions Masami Hiramatsu (Google)
2026-11-10 1:40 ` sashiko-bot [this message]
2026-11-11 13:51 ` Masami Hiramatsu (Google)
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-205975@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox