All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	stable@vger.kernel.org
Subject: Re: [PATCH 4.4 1/3] bpf: fix branch pruning logic
Date: Thu, 1 Feb 2018 09:10:23 +0100	[thread overview]
Message-ID: <20180201081023.GC15896@kroah.com> (raw)
In-Reply-To: <20180131180345.iu37p527g3qiav2f@xylophone.i.decadent.org.uk>

On Wed, Jan 31, 2018 at 06:03:45PM +0000, Ben Hutchings wrote:
> commit c131187db2d3fa2f8bf32fdf4e9a4ef805168467 upstream.
> 
> when the verifier detects that register contains a runtime constant
> and it's compared with another constant it will prune exploration
> of the branch that is guaranteed not to be taken at runtime.
> This is all correct, but malicious program may be constructed
> in such a way that it always has a constant comparison and
> the other branch is never taken under any conditions.
> In this case such path through the program will not be explored
> by the verifier. It won't be taken at run-time either, but since
> all instructions are JITed the malicious program may cause JITs
> to complain about using reserved fields, etc.
> To fix the issue we have to track the instructions explored by
> the verifier and sanitize instructions that are dead at run time
> with NOPs. We cannot reject such dead code, since llvm generates
> it for valid C code, since it doesn't do as much data flow
> analysis as the verifier does.
> 
> Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> [bwh: Backported to 4.4:
>  - s/bpf_verifier_env/verifier_env/
>  - Adjust context]
> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
> ---
>  kernel/bpf/verifier.c | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)

Daniel already provided a backport of this, thanks.

greg k-h

      reply	other threads:[~2018-02-01  8:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31 18:03 [PATCH 4.4 1/3] bpf: fix branch pruning logic Ben Hutchings
2018-02-01  8:10 ` Greg Kroah-Hartman [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=20180201081023.GC15896@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ast@kernel.org \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=daniel@iogearbox.net \
    --cc=stable@vger.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.