Linux Trace Kernel
 help / color / mirror / Atom feed
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

  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