From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: David Vernet <void@manifault.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yhs@meta.com, john.fastabend@gmail.com, kpsingh@kernel.org,
sdf@google.com, haoluo@google.com, jolsa@kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
tj@kernel.org
Subject: Re: [PATCH bpf-next 3/8] bpf: Disallow NULL PTR_TO_MEM for trusted kfuncs
Date: Fri, 20 Jan 2023 10:51:01 +0530 [thread overview]
Message-ID: <20230120052101.sevhc4jybcm6onu2@apollo> (raw)
In-Reply-To: <20230119235833.2948341-4-void@manifault.com>
On Fri, Jan 20, 2023 at 05:28:28AM IST, David Vernet wrote:
> KF_TRUSTED_ARGS kfuncs currently have a subtle and insidious bug in
> validating pointers to scalars. Say that you have a kfunc like the
> following, which takes an array as the first argument:
>
> bool bpf_cpumask_empty(const struct cpumask *cpumask)
> {
> return cpumask_empty(cpumask);
> }
>
> ...
> BTF_ID_FLAGS(func, bpf_cpumask_empty, KF_TRUSTED_ARGS)
> ...
>
This is known and expected.
> If a BPF program were to invoke the kfunc with a NULL argument, it would
> crash the kernel. The reason is that struct cpumask is defined as a
> bitmap, which is itself defined as an array, and is accessed as a memory
> address memory by bitmap operations. So when the verifier analyzes the
> register, it interprets it as a pointer to a scalar struct, which is an
> array of size 8. check_mem_reg() then sees that the register is NULL,
> and returns 0, and the kfunc crashes when it passes it down to the
> cpumask wrappers.
>
> To fix this, this patch adds a check for KF_ARG_PTR_TO_MEM which
> verifies that the register doesn't contain a NULL pointer if the kfunc
> is KF_TRUSTED_ARGS.
>
> This may or may not be desired behavior. Some kfuncs may want to
> allow callers to pass NULL-able pointers. An alternative would be adding
> a KF_NOT_NULL flag and leaving KF_TRUSTED_ARGS alone, though given that
> a kfunc is saying it wants to "trust" an argument, it seems reasonable
> to prevent NULL.
>
> Signed-off-by: David Vernet <void@manifault.com>
> ---
> kernel/bpf/verifier.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 9fa101420046..28ccb92ebe65 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -9092,6 +9092,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> i, btf_type_str(ref_t), ref_tname, PTR_ERR(resolve_ret));
> return -EINVAL;
> }
> + if (is_kfunc_trusted_args(meta) && register_is_null(reg)) {
> + verbose(env, "NULL pointer passed to trusted arg%d\n", i);
> + return -EACCES;
> + }
> +
Current patch looks like a stop gap solution. Just checking for register_is_null
is not enough, what about PTR_MAYBE_NULL? That can also be passed. Some
arguments can be both PTR_TO_BTF_ID and PTR_TO_MEM, so it will be bypassed in
the other case because this check is limited to KF_ARG_PTR_TO_MEM. It would
probably be better to disallow NULL by default and explicitly tag the argument
with __or_null to indicate that NULL is accepted. Seems like a much better
default to me.
next prev parent reply other threads:[~2023-01-20 5:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 23:58 [PATCH bpf-next 0/8] Enable cpumasks to be used as kptrs David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 1/8] bpf: Enable annotating trusted nested pointers David Vernet
2023-01-20 1:14 ` kernel test robot
2023-01-20 2:27 ` David Vernet
2023-01-20 6:01 ` kernel test robot
2023-01-19 23:58 ` [PATCH bpf-next 2/8] bpf: Allow trusted args to walk struct when checking BTF IDs David Vernet
2023-01-20 4:58 ` Kumar Kartikeya Dwivedi
2023-01-20 5:23 ` David Vernet
2023-01-20 5:40 ` Alexei Starovoitov
2023-01-20 5:56 ` Kumar Kartikeya Dwivedi
2023-01-20 6:14 ` Alexei Starovoitov
2023-01-20 14:56 ` David Vernet
2023-01-20 15:26 ` David Vernet
2023-01-20 16:17 ` Alexei Starovoitov
2023-01-19 23:58 ` [PATCH bpf-next 3/8] bpf: Disallow NULL PTR_TO_MEM for trusted kfuncs David Vernet
2023-01-20 5:21 ` Kumar Kartikeya Dwivedi [this message]
2023-01-20 5:31 ` David Vernet
2023-01-20 5:44 ` Alexei Starovoitov
2023-01-19 23:58 ` [PATCH bpf-next 4/8] bpf: Enable cpumasks to be queried and used as kptrs David Vernet
2023-01-20 2:36 ` kernel test robot
2023-01-20 3:39 ` David Vernet
2023-01-20 5:48 ` Alexei Starovoitov
2023-01-20 5:50 ` David Vernet
2023-01-20 5:52 ` Alexei Starovoitov
2023-01-20 6:22 ` kernel test robot
2023-01-19 23:58 ` [PATCH bpf-next 5/8] selftests/bpf: Add nested trust selftests suite David Vernet
2023-01-20 5:51 ` Alexei Starovoitov
2023-01-20 5:56 ` David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 6/8] selftests/bpf: Add selftest suite for cpumask kfuncs David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 7/8] bpf/docs: Document cpumask kfuncs in a new file David Vernet
2023-01-20 5:59 ` Alexei Starovoitov
2023-01-20 6:01 ` David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 8/8] bpf/docs: Document how nested trusted fields may be defined David Vernet
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=20230120052101.sevhc4jybcm6onu2@apollo \
--to=memxor@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=void@manifault.com \
--cc=yhs@meta.com \
/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
all inboxes | Powered by JetHome®