From: Josef Bacik <jbacik@fb.com>
To: Jann Horn <jannh@google.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Cc: <security@kernel.org>, <netdev@vger.kernel.org>
Subject: Re: 484611357c19 introduces arbitrary kernel write bug (root-only)
Date: Tue, 8 Nov 2016 21:02:53 -0500 [thread overview]
Message-ID: <d3c60ae6-7c48-7735-eabd-014d3ece7845@fb.com> (raw)
In-Reply-To: <CAG48ez0mP4xwv6vnKRJ+rcdXYyA1wGnCWsbkKUgWGSBbMtgFMw@mail.gmail.com>
On 11/08/2016 07:23 PM, Jann Horn wrote:
> In 484611357c19 (not in any stable kernel yet), functionality is
> introduced that allows root (and afaics nobody else, since nobody else
> is allowed to perform pointer arithmetic) to basically write to (and
> read from) arbitrary kernel memory. There are multiple bugs in the
> validation logic:
>
> - A bitwise AND of values in the ranges [a,b] and [c,d] is assumed to
> always result in a value
> >= a&b. However, for the combination of ranges [1,1] and [1,2],
> this calculates a minimum of 1
> while actually, 1&2 is zero. This is the bug that my crasher
> (below) triggers.
Ugh crap. I had this logic right before, but changed it to deal with the case
of -value & -value which would make the min_value -value. Instead if min and
max are both positive then the min should be 0. I'll fix this up and add a
testcase, nice catch.
> - a%b is assumed to always be smaller than b-1. However, for b==0,
> this will calculate an upper
> limit of -1 while the values will actually always be zero.
Yup you're right.
> - I'm not sure about this, but I think that, when only one end of the
> range is bounded, the logic will
> incorrectly also treat the other end as a bounded, and because of
> the usage of bound
> placeholders that are smaller than the actual maximum values, this
> could be used to perform
> out-of-bounds accesses.
Yeah I think you're right, if we have register A min bounded at say
REGISTER_MAX_VALUE, and then have register B not min bounded at all so we
default to the REGISTER_MIN_VALUE we and did a add we could end up thinking the
minimum was 0, when it could be anything. I'll fix this as well.
Thanks for looking at all this, I'll get this fixed up in the morning with test
cases and send it out,
Josef
next prev parent reply other threads:[~2016-11-09 2:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 0:23 484611357c19 introduces arbitrary kernel write bug (root-only) Jann Horn
2016-11-09 1:04 ` Andy Lutomirski
2016-11-09 2:02 ` Josef Bacik [this message]
2016-11-09 21:21 ` Josef Bacik
2016-11-09 22:12 ` Jann Horn
2016-11-11 0:18 ` [PATCH] bpf: fix range arithmetic for bpf map access Josef Bacik
2016-11-11 0:46 ` David Miller
2016-11-11 16:36 ` Jann Horn
2016-11-11 19:09 ` Josef Bacik
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=d3c60ae6-7c48-7735-eabd-014d3ece7845@fb.com \
--to=jbacik@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jannh@google.com \
--cc=netdev@vger.kernel.org \
--cc=security@kernel.org \
/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.