BPF List
 help / color / mirror / Atom feed
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(-)
>>
[...]

      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