All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>, Andrey Ignatov <rdna@fb.com>
Subject: Re: [PATCH bpf] bpf: allow narrow loads of bpf_sysctl fields with offset > 0
Date: Tue, 29 Oct 2019 15:19:38 +0100	[thread overview]
Message-ID: <9B04A778-42CE-4451-A276-5A41D6290055@linux.ibm.com> (raw)
In-Reply-To: <CAEf4BzajQL463pCogVAnX1H5Tg-+kj9p_-mAJs=n1r6OfZ2mXg@mail.gmail.com>

> Am 29.10.2019 um 05:36 schrieb Andrii Nakryiko <andrii.nakryiko@gmail.com>:
> 
> On Mon, Oct 28, 2019 at 1:09 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>> 
>> --- a/kernel/bpf/cgroup.c
>> +++ b/kernel/bpf/cgroup.c
>> @@ -1311,12 +1311,12 @@ static bool sysctl_is_valid_access(int off, int size, enum bpf_access_type type,
>>                return false;
>> 
>>        switch (off) {
>> -       case offsetof(struct bpf_sysctl, write):
>> +       case bpf_ctx_range(struct bpf_sysctl, write):
> 
> this will actually allow reads pas t write field (e.g., offset = 2, size = 4).

Wouldn't

	if (off < 0 || off + size > sizeof(struct bpf_sysctl) || off % size)
		return false;

prevent all OOB read-write attempts? Especially the off % size part - I
think it has the effect of preventing OOB accesses for fields. In
particular, it would filter offset = 2, size = 4 case.

I have also checked the other usages of bpf_ctx_range, for example,
bpf_skb_is_valid_access, and they don't seem to be doing anything
special.

> 
>>                if (type != BPF_READ)
>>                        return false;
>>                bpf_ctx_record_field_size(info, size_default);
>>                return bpf_ctx_narrow_access_ok(off, size, size_default);
>> -       case offsetof(struct bpf_sysctl, file_pos):
>> +       case bpf_ctx_range(struct bpf_sysctl, file_pos)
> 
> this will allow read past context struct altogether. When we allow
> ranges, we will have to adjust allowed read size.

Same here.

  reply	other threads:[~2019-10-29 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 12:29 [PATCH bpf] bpf: allow narrow loads of bpf_sysctl fields with offset > 0 Ilya Leoshkevich
2019-10-28 23:59 ` Andrey Ignatov
2019-10-29  4:36 ` Andrii Nakryiko
2019-10-29 14:19   ` Ilya Leoshkevich [this message]
2019-10-29 15:16     ` Andrey Ignatov
2019-10-29 17:39       ` Andrii Nakryiko
2019-10-30 19:54         ` Alexei Starovoitov
2019-10-29 15:19 ` Andrey Ignatov

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=9B04A778-42CE-4451-A276-5A41D6290055@linux.ibm.com \
    --to=iii@linux.ibm.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=rdna@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.