From: Yonghong Song <yhs@fb.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, <kernel-team@fb.com>,
Jiri Olsa <jolsa@kernel.org>, Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH bpf-next v3] bpf: fix NULL pointer dereference in bpf_get_local_storage() helper
Date: Mon, 22 Mar 2021 17:57:51 -0700 [thread overview]
Message-ID: <f2d2b206-07aa-7043-9a0c-ef0a3c3d945f@fb.com> (raw)
In-Reply-To: <YFkCRY+HBvOYj1Y0@krava>
On 3/22/21 1:47 PM, Jiri Olsa wrote:
> On Sat, Mar 20, 2021 at 10:02:01AM -0700, Yonghong Song wrote:
>> Jiri Olsa reported a bug ([1]) in kernel where cgroup local
>> storage pointer may be NULL in bpf_get_local_storage() helper.
>> There are two issues uncovered by this bug:
>> (1). kprobe or tracepoint prog incorrectly sets cgroup local storage
>> before prog run,
>> (2). due to change from preempt_disable to migrate_disable,
>> preemption is possible and percpu storage might be overwritten
>> by other tasks.
>>
>> This issue (1) is fixed in [2]. This patch tried to address issue (2).
>> The following shows how things can go wrong:
>> task 1: bpf_cgroup_storage_set() for percpu local storage
>> preemption happens
>> task 2: bpf_cgroup_storage_set() for percpu local storage
>> preemption happens
>> task 1: run bpf program
>>
>> task 1 will effectively use the percpu local storage setting by task 2
>> which will be either NULL or incorrect ones.
>>
>> Instead of just one common local storage per cpu, this patch fixed
>> the issue by permitting 8 local storages per cpu and each local
>> storage is identified by a task_struct pointer. This way, we
>> allow at most 8 nested preemption between bpf_cgroup_storage_set()
>> and bpf_cgroup_storage_unset(). The percpu local storage slot
>> is released (calling bpf_cgroup_storage_unset()) by the same task
>> after bpf program finished running.
>> bpf_test_run() is also fixed to use the new bpf_cgroup_storage_set()
>> interface.
>>
>> The patch is tested on top of [2] with reproducer in [1].
>> Without this patch, kernel will emit error in 2-3 minutes.
>> With this patch, after one hour, still no error.
>>
>> [1] https://lore.kernel.org/bpf/CAKH8qBuXCfUz=w8L+Fj74OaUpbosO29niYwTki7e3Ag044_aww@mail.gmail.com/T
>> [2] https://lore.kernel.org/bpf/CAKH8qBuXCfUz=w8L+Fj74OaUpbosO29niYwTki7e3Ag044_aww@mail.gmail.com/T
>
> [1] and [2] are same link, you mean this one, right?
> 05a68ce5fa51 bpf: Don't do bpf_cgroup_storage_set() for kuprobe/tp programs
Thanks for spotting this! Will fix it and submit v4.
>
> I have troubles to apply this on bpf-next probably because
> of dependencies, I'll wait for bpf-next is in sync with bpf
> fixes.. or would you have a branch pushed out with this?
I do not have a public branch for this. You can do:
- with latest bpf-next
- cherry-pick 05a68ce5fa51 bpf: Don't do bpf_cgroup_storage_set() for
kuprobe/tp programs
- apply this patch
Then you should be good to go to do a testing. Thanks!
>
> thanks for the fix,
> jirka
>
>>
>> Cc: Jiri Olsa <jolsa@kernel.org>
>> Cc: Roman Gushchin <guro@fb.com>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> include/linux/bpf-cgroup.h | 57 ++++++++++++++++++++++++++++++++------
>> include/linux/bpf.h | 22 ++++++++++++---
>> kernel/bpf/helpers.c | 15 +++++++---
>> kernel/bpf/local_storage.c | 5 ++--
>> net/bpf/test_run.c | 6 +++-
>> 5 files changed, 86 insertions(+), 19 deletions(-)
>>
[...]
prev parent reply other threads:[~2021-03-23 0:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 17:02 [PATCH bpf-next v3] bpf: fix NULL pointer dereference in bpf_get_local_storage() helper Yonghong Song
2021-03-22 18:39 ` Roman Gushchin
2021-03-23 0:55 ` Yonghong Song
2021-03-22 20:47 ` Jiri Olsa
2021-03-23 0:57 ` Yonghong Song [this message]
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=f2d2b206-07aa-7043-9a0c-ef0a3c3d945f@fb.com \
--to=yhs@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=guro@fb.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kernel-team@fb.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