linux-kernel - Re: [PATCH] bpf: Specify access type of bpf_sysctl_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2ecw97mxn.fsf@gmail.com>
Date: Tue, 27 May 2025 14:39:48 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: "Jerome Marchand" <jmarchan@...hat.com>
Cc: bpf@...r.kernel.org,  Martin KaFai Lau <martin.lau@...ux.dev>,  Alexei
 Starovoitov <ast@...nel.org>,  Daniel Borkmann <daniel@...earbox.net>,
  Andrii Nakryiko <andrii@...nel.org>,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Specify access type of bpf_sysctl_get_name args

"Jerome Marchand" <jmarchan@...hat.com> writes:

> The second argument of bpf_sysctl_get_name() helper is a pointer to a
> buffer that is being written to. However that isn't specify in the
> prototype.
>
> Until commit 37cce22dbd51a ("bpf: verifier: Refactor helper access
> type tracking"), all helper accesses were considered as a possible
> write access by the verifier, so no big harm was done. However, since
> then, the verifier might make wrong asssumption about the content of
> that address which might lead it to make faulty optimizations (such as
> removing code that was wrongly labeled dead). This is what happens in
> test_sysctl selftest to the tests related to sysctl_get_name.
>
> Correctly mark the second argument of bpf_sysctl_get_name() as
> ARG_PTR_TO_UNINIT_MEM.
>
> Signed-off-by: Jerome Marchand <jmarchan@...hat.com>
> ---

Looks like we don't run bpf_sysctl_get_name tests on the CI.
CI executes the following binaries:
- test_progs{,-no_alu32,-cpuv4}
- test_verifier
- test_maps
test_progs is what is actively developed.

I agree with the reasoning behind this patch, however, could you please
add a selftest demonstrating unsafe behaviour?
You can use tools/testing/selftests/bpf/progs/verifier_and.c as an
example of verifier test checking for specific log message.
(framework also supports execution if __retval is specified,
 tests can be written in plain C as well, e.g. as in .../iters.c).