diff mbox series

[RFC,bpf-next,1/2] bpf: Fail uprobe multi link with negative offset

Message ID 20231213141234.1210389-1-jolsa@kernel.org (mailing list archive)
State RFC
Delegated to: BPF
Headers show
Series [RFC,bpf-next,1/2] bpf: Fail uprobe multi link with negative offset | expand

Checks

Context Check Description
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-10 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-18 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-next-VM_Test-17 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-42 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18 and -O2 optimization
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17 and -O2 optimization
bpf/vmtest-bpf-next-VM_Test-15 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-13 success Logs for s390x-gcc / test (test_maps, false, 360) / test_maps on s390x with gcc
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for bpf-next
netdev/ynl success SINGLE THREAD; Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1132 this patch: 1132
netdev/cc_maintainers warning 8 maintainers not CCed: kpsingh@kernel.org yonghong.song@linux.dev martin.lau@linux.dev rostedt@goodmis.org song@kernel.org mhiramat@kernel.org mathieu.desnoyers@efficios.com linux-trace-kernel@vger.kernel.org
netdev/build_clang success Errors and warnings before: 1143 this patch: 1143
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 1159 this patch: 1159
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 11 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Jiri Olsa Dec. 13, 2023, 2:12 p.m. UTC 
Currently the __uprobe_register will return 0 (success) when called with
negative offset. The reason is that the call to register_for_each_vma and
then build_map_info won't return error for negative offset. They just won't
do anything - no matching vma is found so there's no registered breakpoint
for the uprobe.

I don't think we can change the behaviour of __uprobe_register and fail
for negative uprobe offset, because apps might depend on that already.

But I think we can still make the change and check for it on bpf multi
link syscall level.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 kernel/trace/bpf_trace.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Alan Maguire Dec. 13, 2023, 5:51 p.m. UTC | #1 
On 13/12/2023 14:12, Jiri Olsa wrote:
> Currently the __uprobe_register will return 0 (success) when called with
> negative offset. The reason is that the call to register_for_each_vma and
> then build_map_info won't return error for negative offset. They just won't
> do anything - no matching vma is found so there's no registered breakpoint
> for the uprobe.
> 
> I don't think we can change the behaviour of __uprobe_register and fail
> for negative uprobe offset, because apps might depend on that already.
> 

just my view, but since passing negative offsets never made sense, I
wouldn't be as worried about breaking existing consumers. Regardless of
what a user thought would happen passing a negative value, nothing did,
so that can't have been their intent.

> But I think we can still make the change and check for it on bpf multi
> link syscall level.
> 
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>

Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  kernel/trace/bpf_trace.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 774cf476a892..0dbf8d9b3ace 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  			goto error_free;
>  		}
>  
> +		if (uprobes[i].offset < 0) {
> +			err = -EINVAL;
> +			goto error_free;
> +		}
> +
>  		uprobes[i].link = link;
>  
>  		if (flags & BPF_F_UPROBE_MULTI_RETURN)
Song Liu Dec. 13, 2023, 11:35 p.m. UTC | #2 
On Wed, Dec 13, 2023 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Currently the __uprobe_register will return 0 (success) when called with
> negative offset. The reason is that the call to register_for_each_vma and
> then build_map_info won't return error for negative offset. They just won't
> do anything - no matching vma is found so there's no registered breakpoint
> for the uprobe.
>
> I don't think we can change the behaviour of __uprobe_register and fail
> for negative uprobe offset, because apps might depend on that already.
>
> But I think we can still make the change and check for it on bpf multi
> link syscall level.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  kernel/trace/bpf_trace.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 774cf476a892..0dbf8d9b3ace 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>                         goto error_free;
>                 }
>
> +               if (uprobes[i].offset < 0) {
> +                       err = -EINVAL;
> +                       goto error_free;
> +               }
> +

nit: We have 3 __get_user() here. How about we move __get_user(offset)
to the first
and check offset immediately after it? This will save us a few
__get_user() in the
error path.

Thanks,
Song

>                 uprobes[i].link = link;
>
>                 if (flags & BPF_F_UPROBE_MULTI_RETURN)
> --
> 2.43.0
>
>
Andrii Nakryiko Dec. 13, 2023, 11:43 p.m. UTC | #3 
On Wed, Dec 13, 2023 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Currently the __uprobe_register will return 0 (success) when called with
> negative offset. The reason is that the call to register_for_each_vma and
> then build_map_info won't return error for negative offset. They just won't
> do anything - no matching vma is found so there's no registered breakpoint
> for the uprobe.
>
> I don't think we can change the behaviour of __uprobe_register and fail
> for negative uprobe offset, because apps might depend on that already.
>
> But I think we can still make the change and check for it on bpf multi
> link syscall level.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  kernel/trace/bpf_trace.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 774cf476a892..0dbf8d9b3ace 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>                         goto error_free;
>                 }
>
> +               if (uprobes[i].offset < 0) {

offset in UAPI is defined as unsigned, so how can it be negative?

> +                       err = -EINVAL;
> +                       goto error_free;
> +               }
> +
>                 uprobes[i].link = link;
>
>                 if (flags & BPF_F_UPROBE_MULTI_RETURN)
> --
> 2.43.0
>
Jiri Olsa Dec. 14, 2023, 9:07 a.m. UTC | #4 
On Wed, Dec 13, 2023 at 03:43:04PM -0800, Andrii Nakryiko wrote:
> On Wed, Dec 13, 2023 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Currently the __uprobe_register will return 0 (success) when called with
> > negative offset. The reason is that the call to register_for_each_vma and
> > then build_map_info won't return error for negative offset. They just won't
> > do anything - no matching vma is found so there's no registered breakpoint
> > for the uprobe.
> >
> > I don't think we can change the behaviour of __uprobe_register and fail
> > for negative uprobe offset, because apps might depend on that already.
> >
> > But I think we can still make the change and check for it on bpf multi
> > link syscall level.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> >  kernel/trace/bpf_trace.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 774cf476a892..0dbf8d9b3ace 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> >                         goto error_free;
> >                 }
> >
> > +               if (uprobes[i].offset < 0) {
> 
> offset in UAPI is defined as unsigned, so how can it be negative?

right, but then it's passed to uprobe_register_refctr as loff_t which is 'long long'

jirka

> 
> > +                       err = -EINVAL;
> > +                       goto error_free;
> > +               }
> > +
> >                 uprobes[i].link = link;
> >
> >                 if (flags & BPF_F_UPROBE_MULTI_RETURN)
> > --
> > 2.43.0
> >
Jiri Olsa Dec. 14, 2023, 9:22 a.m. UTC | #5 
On Wed, Dec 13, 2023 at 03:35:07PM -0800, Song Liu wrote:
> On Wed, Dec 13, 2023 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Currently the __uprobe_register will return 0 (success) when called with
> > negative offset. The reason is that the call to register_for_each_vma and
> > then build_map_info won't return error for negative offset. They just won't
> > do anything - no matching vma is found so there's no registered breakpoint
> > for the uprobe.
> >
> > I don't think we can change the behaviour of __uprobe_register and fail
> > for negative uprobe offset, because apps might depend on that already.
> >
> > But I think we can still make the change and check for it on bpf multi
> > link syscall level.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> >  kernel/trace/bpf_trace.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 774cf476a892..0dbf8d9b3ace 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> >                         goto error_free;
> >                 }
> >
> > +               if (uprobes[i].offset < 0) {
> > +                       err = -EINVAL;
> > +                       goto error_free;
> > +               }
> > +
> 
> nit: We have 3 __get_user() here. How about we move __get_user(offset)
> to the first
> and check offset immediately after it? This will save us a few
> __get_user() in the
> error path.

right, we can move it up

thanks,
jirka

> 
> Thanks,
> Song
> 
> >                 uprobes[i].link = link;
> >
> >                 if (flags & BPF_F_UPROBE_MULTI_RETURN)
> > --
> > 2.43.0
> >
> >
Andrii Nakryiko Dec. 14, 2023, 11:28 p.m. UTC | #6 
On Thu, Dec 14, 2023 at 1:07 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Wed, Dec 13, 2023 at 03:43:04PM -0800, Andrii Nakryiko wrote:
> > On Wed, Dec 13, 2023 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > >
> > > Currently the __uprobe_register will return 0 (success) when called with
> > > negative offset. The reason is that the call to register_for_each_vma and
> > > then build_map_info won't return error for negative offset. They just won't
> > > do anything - no matching vma is found so there's no registered breakpoint
> > > for the uprobe.
> > >
> > > I don't think we can change the behaviour of __uprobe_register and fail
> > > for negative uprobe offset, because apps might depend on that already.
> > >
> > > But I think we can still make the change and check for it on bpf multi
> > > link syscall level.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > ---
> > >  kernel/trace/bpf_trace.c | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > > index 774cf476a892..0dbf8d9b3ace 100644
> > > --- a/kernel/trace/bpf_trace.c
> > > +++ b/kernel/trace/bpf_trace.c
> > > @@ -3397,6 +3397,11 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> > >                         goto error_free;
> > >                 }
> > >
> > > +               if (uprobes[i].offset < 0) {
> >
> > offset in UAPI is defined as unsigned, so how can it be negative?
>
> right, but then it's passed to uprobe_register_refctr as loff_t which is 'long long'

ah, so it's not rejected because uprobe_register expects signed offset
(for some reason...) and it only does

if (offset > i_size_read(inode))

got it, thanks.

>
> jirka
>
> >
> > > +                       err = -EINVAL;
> > > +                       goto error_free;
> > > +               }
> > > +
> > >                 uprobes[i].link = link;
> > >
> > >                 if (flags & BPF_F_UPROBE_MULTI_RETURN)
> > > --
> > > 2.43.0
> > >
diff mbox series

Patch

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 774cf476a892..0dbf8d9b3ace 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -3397,6 +3397,11 @@  int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
 			goto error_free;
 		}
 
+		if (uprobes[i].offset < 0) {
+			err = -EINVAL;
+			goto error_free;
+		}
+
 		uprobes[i].link = link;
 
 		if (flags & BPF_F_UPROBE_MULTI_RETURN)