stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Piotr Krysiuk <piotras@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: [PATCH 4.4 08/20] bpf, x86: Validate computation of branch displacements for x86-64
Date: Fri,  9 Apr 2021 11:53:14 +0200	[thread overview]
Message-ID: <20210409095300.215978921@linuxfoundation.org> (raw)
In-Reply-To: <20210409095259.957388690@linuxfoundation.org>

From: Piotr Krysiuk <piotras@gmail.com>

commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream.

The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.

But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.

And so the optimizer can expand blocks of machine code in some cases.

This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.

To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.

Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/net/bpf_jit_comp.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1038,7 +1038,16 @@ common_load:
 		}
 
 		if (image) {
-			if (unlikely(proglen + ilen > oldproglen)) {
+			/*
+			 * When populating the image, assert that:
+			 *
+			 *  i) We do not write beyond the allocated space, and
+			 * ii) addrs[i] did not change from the prior run, in order
+			 *     to validate assumptions made for computing branch
+			 *     displacements.
+			 */
+			if (unlikely(proglen + ilen > oldproglen ||
+				     proglen + ilen != addrs[i])) {
 				pr_err("bpf_jit_compile fatal error\n");
 				return -EFAULT;
 			}



  parent reply	other threads:[~2021-04-09  9:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09  9:53 [PATCH 4.4 00/20] 4.4.266-rc1 review Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 01/20] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 02/20] mISDN: fix crash in fritzpci Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 03/20] mac80211: choose first enabled channel for monitor Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 04/20] x86/build: Turn off -fcf-protection for realmode targets Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 05/20] ia64: mca: allocate early mca with GFP_ATOMIC Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 06/20] cifs: revalidate mapping when we open files for SMB1 POSIX Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 07/20] cifs: Silently ignore unknown oplock break handle Greg Kroah-Hartman
2021-04-09  9:53 ` Greg Kroah-Hartman [this message]
2021-04-09  9:53 ` [PATCH 4.4 09/20] ALSA: hda/realtek - Fix pincfg for Dell XPS 13 9370 Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 10/20] mtd: rawnand: tmio: Fix the probe error path Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 11/20] mtd: rawnand: socrates: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 12/20] mtd: rawnand: sharpsl: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 13/20] mtd: rawnand: plat_nand: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 14/20] mtd: rawnand: pasemi: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 15/20] mtd: rawnand: orion: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 16/20] mtd: rawnand: diskonchip: " Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 17/20] tracing: Add a vmalloc_sync_mappings() for safe measure Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 18/20] init/Kconfig: make COMPILE_TEST depend on !UML Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 19/20] init/Kconfig: make COMPILE_TEST depend on !S390 Greg Kroah-Hartman
2021-04-09  9:53 ` [PATCH 4.4 20/20] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM Greg Kroah-Hartman
2021-04-09 20:08 ` [PATCH 4.4 00/20] 4.4.266-rc1 review Guenter Roeck
2021-04-10  9:42 ` Naresh Kamboju

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=20210409095300.215978921@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piotras@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).