All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>, bpf@vger.kernel.org
Subject: [PATCH bpf v2 2/2] bpf: Fix hashtab overflow check on 32-bit arches
Date: Thu, 29 Feb 2024 12:22:48 +0100	[thread overview]
Message-ID: <20240229112250.13723-3-toke@redhat.com> (raw)
In-Reply-To: <20240229112250.13723-1-toke@redhat.com>

The hashtab code relies on roundup_pow_of_two() to compute the number of
hash buckets, and contains an overflow check by checking if the resulting
value is 0. However, on 32-bit arches, the roundup code itself can overflow
by doing a 32-bit left-shift of an unsigned long value, which is undefined
behaviour, so it is not guaranteed to truncate neatly. This was triggered
by syzbot on the DEVMAP_HASH type, which contains the same check, copied
from the hashtab code. So apply the same fix to hashtab, by moving the
overflow check to before the roundup.

The hashtab code also contained a check that prevents the total allocation
size for the buckets from overflowing a 32-bit value, but since all the
allocation code uses u64s, this does not really seem to be necessary, so
drop it and keep only the strict overflow check of the n_buckets variable.

Fixes: daaf427c6ab3 ("bpf: fix arraymap NULL deref and missing overflow and zero size checks")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
 kernel/bpf/hashtab.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 03a6a2500b6a..4caf8dab18b0 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -499,8 +499,6 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
 							  num_possible_cpus());
 	}
 
-	/* hash table size must be power of 2 */
-	htab->n_buckets = roundup_pow_of_two(htab->map.max_entries);
 
 	htab->elem_size = sizeof(struct htab_elem) +
 			  round_up(htab->map.key_size, 8);
@@ -510,11 +508,13 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
 		htab->elem_size += round_up(htab->map.value_size, 8);
 
 	err = -E2BIG;
-	/* prevent zero size kmalloc and check for u32 overflow */
-	if (htab->n_buckets == 0 ||
-	    htab->n_buckets > U32_MAX / sizeof(struct bucket))
+	/* prevent overflow in roundup below */
+	if (htab->map.max_entries > U32_MAX / 2 + 1)
 		goto free_htab;
 
+	/* hash table size must be power of 2 */
+	htab->n_buckets = roundup_pow_of_two(htab->map.max_entries);
+
 	err = bpf_map_init_elem_count(&htab->map);
 	if (err)
 		goto free_htab;
-- 
2.43.2


  parent reply	other threads:[~2024-02-29 11:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-29 11:22 [PATCH bpf v2 0/2] Fix hashmap overflow checks for 32-bit arches Toke Høiland-Jørgensen
2024-02-29 11:22 ` [PATCH bpf v2 1/2] bpf: Fix DEVMAP_HASH overflow check on " Toke Høiland-Jørgensen
2024-02-29 11:22 ` Toke Høiland-Jørgensen [this message]
2024-02-29 17:07   ` [PATCH bpf v2 2/2] bpf: Fix hashtab " Alexei Starovoitov
2024-02-29 22:21     ` John Fastabend
2024-03-01 12:35       ` Toke Høiland-Jørgensen
2024-03-01 17:15         ` Alexei Starovoitov
2024-03-04 13:02           ` Toke Høiland-Jørgensen
2024-03-06  5:29             ` Alexei Starovoitov
2024-03-06 10:32               ` Toke Høiland-Jørgensen
2024-03-06 16:53                 ` Alexei Starovoitov
2024-03-07 12:00                   ` Toke Høiland-Jørgensen
2024-03-01 17:21         ` John Fastabend

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=20240229112250.13723-3-toke@redhat.com \
    --to=toke@redhat.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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.