bpf: Fix abuse of kprobe_write_ctx via freplace

PATCH Superseded Leon Hwang 4 participants 12 messages Mar 26 – Mar 30

Subsystems (4)

Kselftest BPF BPF selftests BPF core

lore

Share & tools

lore

Leon Hwang

author

2026-03-26 14:17 UTC #0 lore raw

v2 cover bpf: Fix abuse of kprobe_write_ctx via freplace

The potential issue of kprobe_write_ctx+freplace was mentioned in "bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs" [1].

It is true issue, that the test in patch #2 verifies that kprobe_write_ctx=false kprobe progs can be abused to modify struct pt_regs via kprobe_write_ctx=true freplace progs.

When struct pt_regs is modified, bpf_prog_test_run_opts() gets -EFAULT instead of 0.

test_freplace_kprobe_write_ctx:FAIL:bpf_prog_test_run_opts unexpected error: -14 (errno 14)

We will disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.

Links:
[1] https://lore.kernel.org/bpf/CAP01T74w4KVMn9bEwpQXrk+bqcUxzb6VW1SQ_QvNy0A4EY-9Jg@mail.gmail.com/

Changes:
v1 -> v2:
* Drop patch #1 in v1, as it wasn't an issue (per Toke).
* Check kprobe_write_ctx value at attach time instead of at load time, to prevent attaching kprobe_write_ctx=true freplace progs on kprobe_write_ctx=false kprobe progs (per Gemini/sashiko).
* Move kprobe_write_ctx test code to attach_probe.c and kprobe_write_ctx.c.
v1: https://lore.kernel.org/bpf/[email protected]/

Leon Hwang (2):
bpf: Fix abuse of kprobe_write_ctx via freplace selftests/bpf: Add test to verify the fix of kprobe_write_ctx abuse

 kernel/bpf/syscall.c                          |  5 ++
 .../selftests/bpf/prog_tests/attach_probe.c   | 64 +++++++++++++++++++
 .../selftests/bpf/progs/kprobe_write_ctx.c    | 19 ++++++
 3 files changed, 88 insertions(+)

Signature · 1 line

2.53.0

Leon Hwang

author

2026-03-26 14:17 UTC #1 lore raw

PATCH v2 1/2 bpf: Fix abuse of kprobe_write_ctx via freplace

uprobe programs are allowed to modify struct pt_regs.

Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions.

For example,

SEC("?kprobe")
int kprobe(struct pt_regs *regs)

{
	return 0;
}

SEC("?freplace")
int freplace_kprobe(struct pt_regs *regs)

{
	regs->di = 0;
	return 0;
}

freplace_kprobe prog will attach to kprobe prog.
kprobe prog will attach to a kernel function.

Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog.

To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.

Fixes 7384893d970e ("bpf: Allow uprobe program to change context registers")

Signed-off-by Leon Hwang <[email protected]>

---
 kernel/bpf/syscall.c | 5 +++++
 1 file changed, 5 insertions(+)

kernel/bpf/syscall.c +5 -0

index 51ade3cde8bb..1dd2ea076d8b 100644
@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
 		tr = prog->aux->dst_trampoline;
 		tgt_prog = prog->aux->dst_prog;
 	}
+	if (prog->type == BPF_PROG_TYPE_EXT &&
+	    prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+		err = -EINVAL;
+		goto out_unlock;
+	}
 
 	err = bpf_link_prime(&link->link.link, &link_primer);
 	if (err)

Signature · 1 line

2.53.0

Song Liu

reviewer

2026-03-27 21:39 UTC #2 lore raw

Quoted 43 lines · Leon Hwang

uprobe programs are allowed to modify struct pt_regs.
Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions.
For example,
SEC("?kprobe")
int kprobe(struct pt_regs *regs)
{
        return 0;
}
SEC("?freplace")
int freplace_kprobe(struct pt_regs *regs)
{
        regs->di = 0;
        return 0;
}
freplace_kprobe prog will attach to kprobe prog.
kprobe prog will attach to a kernel function.
Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog.
To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.
Fixes 7384893d970e ("bpf: Allow uprobe program to change context registers")
Signed-off-by Leon Hwang <[email protected]>
---
 kernel/bpf/syscall.c | 5 +++++
 1 file changed, 5 insertions(+)
kernel/bpf/syscall.c +0 -0
index 51ade3cde8bb..1dd2ea076d8b 100644

kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3740

Quoted 8 lines

kernel/bpf/syscall.c +5 -0

@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
                tr = prog->aux->dst_trampoline;
                tgt_prog = prog->aux->dst_prog;
        }
+       if (prog->type == BPF_PROG_TYPE_EXT &&
+           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+               err = -EINVAL;
+               goto out_unlock;
+       }

This also blocks uprobe+freplace when prog and tgt_prog have different kprobe_write_ctx, right? Is this the expected behavior?

Thanks,
Song

Leon Hwang

author

2026-03-30 05:38 UTC #3 lore raw

Quoted 1 line · Song Liu

On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <[email protected]> wrote:

[...]

Quoted 4 lines

kernel/bpf/syscall.c +0 -0

@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
                tr = prog->aux->dst_trampoline;
                tgt_prog = prog->aux->dst_prog;
        }

Quoted 9 lines

kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3740
Quoted 5 lines
kernel/bpf/syscall.c +5 -0
+       if (prog->type == BPF_PROG_TYPE_EXT &&
+           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+               err = -EINVAL;
+               goto out_unlock;
+       }
This also blocks uprobe+freplace when prog and tgt_prog have different kprobe_write_ctx, right? Is this the expected behavior?

Intuitively, yes, this also blocks uprobe+freplace.

However, how can we distinguish uprobe/kprobe here?

At attach time, uprobe/kprobe is recognized by the target perf event flags instead of BPF prog's expected_attach_type. Thus, we cannot infer the use of prog by prog itself.

If we can distinguish them here, I'd like to do it.

Thanks,
Leon

Song Liu

reviewer

2026-03-30 16:44 UTC #4 lore raw

Quoted 18 lines · Leon Hwang

Quoted 1 line · Song Liu
On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <[email protected]> wrote:
[...]
Quoted 4 lines
Quoted 4 lines
kernel/bpf/syscall.c +0 -0
@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
                tr = prog->aux->dst_trampoline;
                tgt_prog = prog->aux->dst_prog;
        }
Quoted 9 lines
kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3740
Quoted 5 lines
kernel/bpf/syscall.c +5 -0
+       if (prog->type == BPF_PROG_TYPE_EXT &&
+           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+               err = -EINVAL;
+               goto out_unlock;
+       }
This also blocks uprobe+freplace when prog and tgt_prog have different kprobe_write_ctx, right? Is this the expected behavior?

Quoted 7 lines

Intuitively, yes, this also blocks uprobe+freplace.
However, how can we distinguish uprobe/kprobe here?
At attach time, uprobe/kprobe is recognized by the target perf event flags instead of BPF prog's expected_attach_type. Thus, we cannot infer the use of prog by prog itself.

Maybe we should introduce an attach type BPF_TRACE_UPROBE in a backward compatible way:
- expected_attach_type = 0, it could be either kprobe or uprobe.
- expected_attach_type = BPF_TRACE_UPROBE, it must be an uprobe.

With this flag, we can allow uprobe+freplace when the user space sets BPF_TRACE_UPROBE properly. WDYT?

Thanks,
Song

Alexei Starovoitov

2026-03-30 17:09 UTC #5 lore raw

Quoted 28 lines · Song Liu

Quoted 18 lines · Leon Hwang
Quoted 1 line · Song Liu
On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <[email protected]> wrote:
[...]
Quoted 4 lines
Quoted 4 lines
kernel/bpf/syscall.c +0 -0
@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
                tr = prog->aux->dst_trampoline;
                tgt_prog = prog->aux->dst_prog;
        }
Quoted 9 lines
kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3740
Quoted 5 lines
kernel/bpf/syscall.c +5 -0
+       if (prog->type == BPF_PROG_TYPE_EXT &&
+           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+               err = -EINVAL;
+               goto out_unlock;
+       }
This also blocks uprobe+freplace when prog and tgt_prog have different kprobe_write_ctx, right? Is this the expected behavior?
Quoted 7 lines
Intuitively, yes, this also blocks uprobe+freplace.
However, how can we distinguish uprobe/kprobe here?
At attach time, uprobe/kprobe is recognized by the target perf event flags instead of BPF prog's expected_attach_type. Thus, we cannot infer the use of prog by prog itself.

Quoted 7 lines

Maybe we should introduce an attach type BPF_TRACE_UPROBE in a backward compatible way:
- expected_attach_type = 0, it could be either kprobe or uprobe.
- expected_attach_type = BPF_TRACE_UPROBE, it must be an uprobe.
With this flag, we can allow uprobe+freplace when the user space sets BPF_TRACE_UPROBE properly. WDYT?

New uapi just to fix a narrow bug? Not a good tradeoff.

Song Liu

reviewer Acked-by

2026-03-30 17:20 UTC #6 lore raw

Quoted 35 lines · Alexei Starovoitov

Quoted 33 lines · Song Liu
Quoted 18 lines · Leon Hwang
Quoted 1 line · Song Liu
On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <[email protected]> wrote:
[...]
Quoted 4 lines
Quoted 4 lines
kernel/bpf/syscall.c +0 -0
@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
                tr = prog->aux->dst_trampoline;
                tgt_prog = prog->aux->dst_prog;
        }
Quoted 9 lines
kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3740
Quoted 5 lines
kernel/bpf/syscall.c +5 -0
+       if (prog->type == BPF_PROG_TYPE_EXT &&
+           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+               err = -EINVAL;
+               goto out_unlock;
+       }
This also blocks uprobe+freplace when prog and tgt_prog have different kprobe_write_ctx, right? Is this the expected behavior?
Quoted 7 lines
Intuitively, yes, this also blocks uprobe+freplace.
However, how can we distinguish uprobe/kprobe here?
At attach time, uprobe/kprobe is recognized by the target perf event flags instead of BPF prog's expected_attach_type. Thus, we cannot infer the use of prog by prog itself.
Maybe we should introduce an attach type BPF_TRACE_UPROBE in a backward compatible way:
- expected_attach_type = 0, it could be either kprobe or uprobe.
- expected_attach_type = BPF_TRACE_UPROBE, it must be an uprobe.

Quoted 4 lines

Quoted 2 lines
With this flag, we can allow uprobe+freplace when the user space sets BPF_TRACE_UPROBE properly. WDYT?
New uapi just to fix a narrow bug? Not a good tradeoff.

Agreed.

Maybe we should just land this set as-is and accept uprobe+freplace won't work in certain cases. In this case:

Acked-by Song Liu <[email protected]>

Thanks,
Song

Jiri Olsa

Acked-by on v2 1/2

2026-03-30 09:28 UTC #7 lore raw

In reply to Leon Hwang

Quoted 42 lines · Leon Hwang

uprobe programs are allowed to modify struct pt_regs.
Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions.
For example,
SEC("?kprobe")
int kprobe(struct pt_regs *regs)
{
	return 0;
}
SEC("?freplace")
int freplace_kprobe(struct pt_regs *regs)
{
	regs->di = 0;
	return 0;
}
freplace_kprobe prog will attach to kprobe prog.
kprobe prog will attach to a kernel function.
Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog.
To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.
Fixes 7384893d970e ("bpf: Allow uprobe program to change context registers")
Signed-off-by Leon Hwang <[email protected]>
---
 kernel/bpf/syscall.c | 5 +++++
 1 file changed, 5 insertions(+)
kernel/bpf/syscall.c +0 -0
index 51ade3cde8bb..1dd2ea076d8b 100644

kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3735

Quoted 3 lines

kernel/bpf/syscall.c +0 -0

@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
 		tr = prog->aux->dst_trampoline;
 		tgt_prog = prog->aux->dst_prog;
 	}

could you please put some comment in here explaining the check, with that

Acked-by Jiri Olsa <[email protected]>

thanks,
jirka

Quoted 11 lines

kernel/bpf/syscall.c +5 -0

+	if (prog->type == BPF_PROG_TYPE_EXT &&
+	    prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
+		err = -EINVAL;
+		goto out_unlock;
+	}
 
 	err = bpf_link_prime(&link->link.link, &link_primer);
 	if (err)

Signature · 1 line

2.53.0

Leon Hwang

author

2026-03-30 13:52 UTC #8 lore raw

Quoted 1 line · Jiri Olsa

On Thu, Mar 26, 2026 at 10:17:17PM +0800, Leon Hwang wrote:

[...]

Quoted 11 lines

kernel/bpf/syscall.c static int bpf_tracing_prog_attach(struct bpf_prog *prog, · line 3735
Quoted 8 lines
kernel/bpf/syscall.c +0 -0
index 51ade3cde8bb..1dd2ea076d8b 100644
@@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
 		tr = prog->aux->dst_trampoline;
 		tgt_prog = prog->aux->dst_prog;
 	}
could you please put some comment in here explaining the check, with that

Sure, will add such comment:

/*
* It is to prevent modifying struct pt_regs via kprobe_write_ctx=true
* freplace prog. Without this check, kprobe_write_ctx=true freplace
* prog is allowed to attach to kprobe_write_ctx=false kprobe prog, and
* then modify the registers of the kprobe prog's target kernel
* function.
*
* This also blocks the combination of uprobe+freplace, because it is
* unable to recognize the use of the tgt_prog as an uprobe or a kprobe
* by tgt_prog itself. At attach time, uprobe/kprobe is recognized by
* the target perf event flags in __perf_event_set_bpf_prog(). */

Quoted 2 lines

Acked-by Jiri Olsa <[email protected]>

Thanks for your review.

Thanks,
Leon

Leon Hwang

author

2026-03-26 14:17 UTC #9 lore raw

PATCH v2 2/2 selftests/bpf: Add test to verify the fix of kprobe_write_ctx abuse

In reply to Leon Hwang

Add a test to verify the issue: kprobe_write_ctx can be abused to modify struct pt_regs of kernel functions via kprobe_write_ctx=true freplace progs.

Without the fix, the issue is verified:

kprobe_write_ctx=true freplace prog is allowed to attach to kprobe_write_ctx=false kprobe prog. Then, the first arg of bpf_fentry_test1 will be set as 0, and bpf_prog_test_run_opts() gets -EFAULT instead of 0.

With the fix, the issue is rejected at attach time.

Signed-off-by Leon Hwang <[email protected]>

---
 .../selftests/bpf/prog_tests/attach_probe.c   | 64 +++++++++++++++++++
 .../selftests/bpf/progs/kprobe_write_ctx.c    | 19 ++++++
 2 files changed, 83 insertions(+)

tools/testing/selftests/bpf/prog_tests/attach_probe.c +64 -0

index 9e77e5da7097..4d253900c4ad 100644
@@ -220,11 +220,73 @@ static void test_attach_kprobe_write_ctx(void)
 
 	kprobe_write_ctx__destroy(skel);
 }
+
+static void test_freplace_kprobe_write_ctx(void)
+{
+	struct bpf_program *prog_kprobe, *prog_ext, *prog_fentry;
+	struct kprobe_write_ctx *skel_kprobe, *skel_ext = NULL;
+	struct bpf_link *link_kprobe = NULL, *link_ext = NULL;
+	int err, prog_fd;
+	LIBBPF_OPTS(bpf_kprobe_opts, kprobe_opts);
+	LIBBPF_OPTS(bpf_test_run_opts, topts);
+
+	skel_kprobe = kprobe_write_ctx__open();
+	if (!ASSERT_OK_PTR(skel_kprobe, "kprobe_write_ctx__open kprobe"))
+		return;
+
+	prog_kprobe = skel_kprobe->progs.kprobe_dummy;
+	bpf_program__set_autoload(prog_kprobe, true);
+
+	prog_fentry = skel_kprobe->progs.fentry;
+	bpf_program__set_autoload(prog_fentry, true);
+
+	err = kprobe_write_ctx__load(skel_kprobe);
+	if (!ASSERT_OK(err, "kprobe_write_ctx__load kprobe"))
+		goto out;
+
+	skel_ext = kprobe_write_ctx__open();
+	if (!ASSERT_OK_PTR(skel_ext, "kprobe_write_ctx__open ext"))
+		goto out;
+
+	prog_ext = skel_ext->progs.freplace_kprobe;
+	bpf_program__set_autoload(prog_ext, true);
+
+	prog_fd = bpf_program__fd(skel_kprobe->progs.kprobe_write_ctx);
+	bpf_program__set_attach_target(prog_ext, prog_fd, "kprobe_write_ctx");
+
+	err = kprobe_write_ctx__load(skel_ext);
+	if (!ASSERT_OK(err, "kprobe_write_ctx__load ext"))
+		goto out;
+
+	prog_fd = bpf_program__fd(prog_kprobe);
+	link_ext = bpf_program__attach_freplace(prog_ext, prog_fd, "kprobe_dummy");
+	ASSERT_ERR_PTR(link_ext, "bpf_program__attach_freplace link");
+	ASSERT_EQ(errno, EINVAL, "bpf_program__attach_freplace errno");
+
+	link_kprobe = bpf_program__attach_kprobe_opts(prog_kprobe, "bpf_fentry_test1",
+						      &kprobe_opts);
+	if (!ASSERT_OK_PTR(link_kprobe, "bpf_program__attach_kprobe_opts"))
+		goto out;
+
+	err = bpf_prog_test_run_opts(bpf_program__fd(prog_fentry), &topts);
+	ASSERT_OK(err, "bpf_prog_test_run_opts");
+
+out:
+	bpf_link__destroy(link_ext);
+	bpf_link__destroy(link_kprobe);
+	kprobe_write_ctx__destroy(skel_ext);
+	kprobe_write_ctx__destroy(skel_kprobe);
+}
 #else
 static void test_attach_kprobe_write_ctx(void)
 {
 	test__skip();
 }
+
+static void test_freplace_kprobe_write_ctx(void)
+{
+	test__skip();
+}
 #endif
 
 static void test_attach_probe_auto(struct test_attach_probe *skel)

@@ -434,6 +496,8 @@ void test_attach_probe(void)
 		test_attach_kprobe_long_event_name();
 	if (test__start_subtest("kprobe-write-ctx"))
 		test_attach_kprobe_write_ctx();
+	if (test__start_subtest("freplace-kprobe-write-ctx"))
+		test_freplace_kprobe_write_ctx();
 
 cleanup:
 	test_attach_probe__destroy(skel);

tools/testing/selftests/bpf/progs/kprobe_write_ctx.c +19 -0

index f77aef0474d3..adbf52afe490 100644
@@ -19,4 +19,23 @@ int kprobe_multi_write_ctx(struct pt_regs *ctx)
 	ctx->ax = 0;
 	return 0;
 }
+
+SEC("?kprobe")
+int kprobe_dummy(struct pt_regs *regs)
+{
+	return 0;
+}
+
+SEC("?freplace")
+int freplace_kprobe(struct pt_regs *regs)
+{
+	regs->di = 0;
+	return 0;
+}
+
+SEC("?fentry/bpf_fentry_test1")
+int BPF_PROG(fentry)
+{
+	return 0;
+}
 #endif

Signature · 1 line

2.53.0

Jiri Olsa

Acked-by on v2 2/2

2026-03-30 09:29 UTC #10 lore raw

Re: [PATCH bpf-next v2 2/2] selftests/bpf: Add test to verify the fix of kprobe_write_ctx abuse

On Thu, Mar 26, 2026 at 10:17:18PM +0800, Leon Hwang wrote:

SNIP

tools/testing/selftests/bpf/prog_tests/attach_probe.c static void test_attach_kprobe_write_ctx(void) · line 264

Quoted 11 lines

tools/testing/selftests/bpf/prog_tests/attach_probe.c +11 -0

+	prog_fd = bpf_program__fd(skel_kprobe->progs.kprobe_write_ctx);
+	bpf_program__set_attach_target(prog_ext, prog_fd, "kprobe_write_ctx");
+
+	err = kprobe_write_ctx__load(skel_ext);
+	if (!ASSERT_OK(err, "kprobe_write_ctx__load ext"))
+		goto out;
+
+	prog_fd = bpf_program__fd(prog_kprobe);
+	link_ext = bpf_program__attach_freplace(prog_ext, prog_fd, "kprobe_dummy");
+	ASSERT_ERR_PTR(link_ext, "bpf_program__attach_freplace link");
+	ASSERT_EQ(errno, EINVAL, "bpf_program__attach_freplace errno");

nit, I prefer libbpf_get_error call instead, because it's not obvious that ASSERT_ERR_PTR sets errno, smth like:

        if (!ASSERT_EQ(libbpf_get_error(link_ext), -EINVAL, ..

anyway lgtm

Acked-by Jiri Olsa <[email protected]>

thanks,
jirka

Quoted 68 lines

tools/testing/selftests/bpf/prog_tests/attach_probe.c +22 -0

+
+	link_kprobe = bpf_program__attach_kprobe_opts(prog_kprobe, "bpf_fentry_test1",
+						      &kprobe_opts);
+	if (!ASSERT_OK_PTR(link_kprobe, "bpf_program__attach_kprobe_opts"))
+		goto out;
+
+	err = bpf_prog_test_run_opts(bpf_program__fd(prog_fentry), &topts);
+	ASSERT_OK(err, "bpf_prog_test_run_opts");
+
+out:
+	bpf_link__destroy(link_ext);
+	bpf_link__destroy(link_kprobe);
+	kprobe_write_ctx__destroy(skel_ext);
+	kprobe_write_ctx__destroy(skel_kprobe);
+}
 #else
 static void test_attach_kprobe_write_ctx(void)
 {
 	test__skip();
 }
+
+static void test_freplace_kprobe_write_ctx(void)
+{
+	test__skip();
+}
 #endif
 
 static void test_attach_probe_auto(struct test_attach_probe *skel)

@@ -434,6 +496,8 @@ void test_attach_probe(void)
 		test_attach_kprobe_long_event_name();
 	if (test__start_subtest("kprobe-write-ctx"))
 		test_attach_kprobe_write_ctx();
+	if (test__start_subtest("freplace-kprobe-write-ctx"))
+		test_freplace_kprobe_write_ctx();
 
 cleanup:
 	test_attach_probe__destroy(skel);

tools/testing/selftests/bpf/progs/kprobe_write_ctx.c +19 -0

index f77aef0474d3..adbf52afe490 100644
@@ -19,4 +19,23 @@ int kprobe_multi_write_ctx(struct pt_regs *ctx)
 	ctx->ax = 0;
 	return 0;
 }
+
+SEC("?kprobe")
+int kprobe_dummy(struct pt_regs *regs)
+{
+	return 0;
+}
+
+SEC("?freplace")
+int freplace_kprobe(struct pt_regs *regs)
+{
+	regs->di = 0;
+	return 0;
+}
+
+SEC("?fentry/bpf_fentry_test1")
+int BPF_PROG(fentry)
+{
+	return 0;
+}
 #endif

Signature · 1 line

2.53.0

Leon Hwang

author

2026-03-30 13:55 UTC #11 lore raw

Re: [PATCH bpf-next v2 2/2] selftests/bpf: Add test to verify the fix of kprobe_write_ctx abuse

Quoted 19 lines · Jiri Olsa

On Thu, Mar 26, 2026 at 10:17:18PM +0800, Leon Hwang wrote:
SNIP
tools/testing/selftests/bpf/prog_tests/attach_probe.c static void test_attach_kprobe_write_ctx(void) · line 264
Quoted 11 lines
tools/testing/selftests/bpf/prog_tests/attach_probe.c +11 -0
+	prog_fd = bpf_program__fd(skel_kprobe->progs.kprobe_write_ctx);
+	bpf_program__set_attach_target(prog_ext, prog_fd, "kprobe_write_ctx");
+
+	err = kprobe_write_ctx__load(skel_ext);
+	if (!ASSERT_OK(err, "kprobe_write_ctx__load ext"))
+		goto out;
+
+	prog_fd = bpf_program__fd(prog_kprobe);
+	link_ext = bpf_program__attach_freplace(prog_ext, prog_fd, "kprobe_dummy");
+	ASSERT_ERR_PTR(link_ext, "bpf_program__attach_freplace link");
+	ASSERT_EQ(errno, EINVAL, "bpf_program__attach_freplace errno");
nit, I prefer libbpf_get_error call instead, because it's not obvious that ASSERT_ERR_PTR sets errno, smth like:

Quoted 2 lines

        if (!ASSERT_EQ(libbpf_get_error(link_ext), -EINVAL, ..

Yeah, libbpf_get_error() is better. Will use it.

Quoted 4 lines

anyway lgtm
Acked-by Jiri Olsa <[email protected]>

Thanks for your review.

Thanks,
Leon

[...]