All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: jslaby@suse.cz, ast@kernel.org, daniel@iogearbox.net,
	gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "bpf, array: fix overflow in max_entries and undefined behavior in index_mask" has been added to the 4.4-stable tree
Date: Sat, 13 Jan 2018 16:39:53 +0100	[thread overview]
Message-ID: <1515857993211157@kroah.com> (raw)
In-Reply-To: <20180112165805.10791-1-jslaby@suse.cz>


This is a note to let you know that I've just added the patch titled

    bpf, array: fix overflow in max_entries and undefined behavior in index_mask

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From jslaby@suse.cz  Sat Jan 13 16:20:05 2018
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 12 Jan 2018 17:58:05 +0100
Subject: bpf, array: fix overflow in max_entries and undefined behavior in index_mask
To: gregkh@linuxfoundation.org
Cc: stable@vger.kernel.org, ast@kernel.org, netdev@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>, Jiri Slaby <jslaby@suse.cz>
Message-ID: <20180112165805.10791-1-jslaby@suse.cz>

From: Daniel Borkmann <daniel@iogearbox.net>

commit bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1 upstream.

syzkaller tried to alloc a map with 0xfffffffd entries out of a userns,
and thus unprivileged. With the recently added logic in b2157399cc98
("bpf: prevent out-of-bounds speculation") we round this up to the next
power of two value for max_entries for unprivileged such that we can
apply proper masking into potentially zeroed out map slots.

However, this will generate an index_mask of 0xffffffff, and therefore
a + 1 will let this overflow into new max_entries of 0. This will pass
allocation, etc, and later on map access we still enforce on the original
attr->max_entries value which was 0xfffffffd, therefore triggering GPF
all over the place. Thus bail out on overflow in such case.

Moreover, on 32 bit archs roundup_pow_of_two() can also not be used,
since fls_long(max_entries - 1) can result in 32 and 1UL << 32 in 32 bit
space is undefined. Therefore, do this by hand in a 64 bit variable.

This fixes all the issues triggered by syzkaller's reproducers.

Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation")
Reported-by: syzbot+b0efb8e572d01bce1ae0@syzkaller.appspotmail.com
Reported-by: syzbot+6c15e9744f75f2364773@syzkaller.appspotmail.com
Reported-by: syzbot+d2f5524fb46fd3b312ee@syzkaller.appspotmail.com
Reported-by: syzbot+61d23c95395cc90dbc2b@syzkaller.appspotmail.com
Reported-by: syzbot+0d363c942452cca68c01@syzkaller.appspotmail.com
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 kernel/bpf/arraymap.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -23,6 +23,7 @@ static struct bpf_map *array_map_alloc(u
 	u32 elem_size, array_size, index_mask, max_entries;
 	bool unpriv = !capable(CAP_SYS_ADMIN);
 	struct bpf_array *array;
+	u64 mask64;
 
 	/* check sanity of attributes */
 	if (attr->max_entries == 0 || attr->key_size != 4 ||
@@ -38,13 +39,25 @@ static struct bpf_map *array_map_alloc(u
 	elem_size = round_up(attr->value_size, 8);
 
 	max_entries = attr->max_entries;
-	index_mask = roundup_pow_of_two(max_entries) - 1;
 
-	if (unpriv)
+	/* On 32 bit archs roundup_pow_of_two() with max_entries that has
+	 * upper most bit set in u32 space is undefined behavior due to
+	 * resulting 1U << 32, so do it manually here in u64 space.
+	 */
+	mask64 = fls_long(max_entries - 1);
+	mask64 = 1ULL << mask64;
+	mask64 -= 1;
+
+	index_mask = mask64;
+	if (unpriv) {
 		/* round up array size to nearest power of 2,
 		 * since cpu will speculate within index_mask limits
 		 */
 		max_entries = index_mask + 1;
+		/* Check for overflows. */
+		if (max_entries < attr->max_entries)
+			return ERR_PTR(-E2BIG);
+	}
 
 	/* check round_up into zero and u32 overflow */
 	if (elem_size == 0 ||


Patches currently in stable-queue which might be from jslaby@suse.cz are

queue-4.4/bpf-adjust-insn_aux_data-when-patching-insns.patch
queue-4.4/hwrng-core-sleep-interruptible-in-read.patch
queue-4.4/bpf-refactor-fixup_bpf_calls.patch
queue-4.4/bpf-array-fix-overflow-in-max_entries-and-undefined-behavior-in-index_mask.patch
queue-4.4/bpf-don-t-ab-use-instructions-to-store-state.patch
queue-4.4/bpf-prevent-out-of-bounds-speculation.patch
queue-4.4/bpf-add-bpf_patch_insn_single-helper.patch
queue-4.4/bpf-move-fixup_bpf_calls-function.patch

  reply	other threads:[~2018-01-13 15:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 16:17 [PATCH 4.4-stable 0/6] bpf: prevent out-of-bounds speculation Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 1/6] bpf: add bpf_patch_insn_single helper Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 2/6] bpf: don't (ab)use instructions to store state Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 3/6] bpf: move fixup_bpf_calls() function Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 4/6] bpf: refactor fixup_bpf_calls() Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 5/6] bpf: adjust insn_aux_data when patching insns Jiri Slaby
2018-01-12 16:17 ` [PATCH 4.4-stable 6/6] bpf: prevent out-of-bounds speculation Jiri Slaby
2018-01-12 16:52   ` Eric Dumazet
2018-01-12 16:28 ` [PATCH 4.4-stable 0/6] " Daniel Borkmann
2018-01-12 16:58 ` [PATCH 4.4-stable 7/7] bpf, array: fix overflow in max_entries and undefined behavior in index_mask Jiri Slaby
2018-01-13 15:39   ` gregkh [this message]
2018-01-13 19:49 ` [PATCH 4.4-stable 0/6] bpf: prevent out-of-bounds speculation Greg KH

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=1515857993211157@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jslaby@suse.cz \
    --cc=stable-commits@vger.kernel.org \
    --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.