All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Matei <andreimatei1@gmail.com>
To: bpf@vger.kernel.org
Cc: alexei.starovoitov@gmail.com,
	Andrei Matei <andreimatei1@gmail.com>,
	syzbot+33f4297b5f927648741a@syzkaller.appspotmail.com
Subject: [PATCH bpf] bpf: Protect against int overflow for stack access size
Date: Sun, 24 Mar 2024 19:03:23 -0400	[thread overview]
Message-ID: <20240324230323.1097685-1-andreimatei1@gmail.com> (raw)

This patch re-introduces protection against the size of access to stack
memory being negative; the access size can appear negative as a result
of overflowing its signed int representation (the respective function
arguments is sometimes converted from a u32 and u64 without any overflow
checking), and causes out-of-bounds array accesses in
check_stack_range_initialized(). This patch causes the verification of a
program with such a non-sensical access size to fail.

This check used to exist in a more indirect way, but was inadvertendly
removed in a833a17a.

This omission was found by syzkaller. I have failed to actually create a
program that triggers the issue (different other protections kick in for
different code paths). The syzkaller program is opaque and I failed to
fully decipher it; from what I gather, it declares a map with a huge
value type (0x80000001 bytes, which is INT_MAX + 2), and somehow calls a
helper (bpf_map_peek_elem), and manages to pass to it a pointer to the
stack while, at the same time, the size of values in this map is being
used as the "access size".

Fixes: a833a17a ("bpf: Fix verification of indirect var-off stack access")
Reported-by: syzbot+33f4297b5f927648741a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/bpf/CAADnVQLORV5PT0iTAhRER+iLBTkByCYNBYyvBSgjN1T31K+gOw@mail.gmail.com/
---
 kernel/bpf/verifier.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 0bfc0050db28..2019d6177969 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6701,6 +6701,8 @@ static int check_stack_access_within_bounds(
 	err = check_stack_slot_within_bounds(env, min_off, state, type);
 	if (!err && max_off > 0)
 		err = -EINVAL; /* out of stack access into non-negative offsets */
+	if (!err && access_size < 0)
+		err = -EINVAL; /* invalid negative access size; integer overflow? */
 
 	if (err) {
 		if (tnum_is_const(reg->var_off)) {
-- 
2.40.1


             reply	other threads:[~2024-03-24 23:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-24 23:03 Andrei Matei [this message]
2024-03-25  1:07 ` [PATCH bpf] bpf: Protect against int overflow for stack access size Alexei Starovoitov
2024-03-26  2:56   ` Andrei Matei

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=20240324230323.1097685-1-andreimatei1@gmail.com \
    --to=andreimatei1@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=syzbot+33f4297b5f927648741a@syzkaller.appspotmail.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.