From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2F6A17E3D8; Sun, 24 Mar 2024 22:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; cv=none; b=cJux1mgNn82nFZpVLw+tJRPU9pKQUW7WNUrN4DRAgKbjdTh1NsXoqBiJgkdQTlfxwWaVWoTIOGZm1SAJ0pHjBB1qFAjPje86oInREoifD62hFX4mtlgmMVaGjR3OMCFJ3goaa3TseduLJdLcR5A+NJEe8dfchJbMchgYuLCD3QM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; c=relaxed/simple; bh=r+eUaeSBbJITi10eWBdwYxrKWd/L8nsqR8864q3AH38=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nmG55iG2PERfhGgYfS3fbmZNSg8VtBI6N6UH+mVKrqS+CsjlWWEqz2eot/xnBaA6n4jtozyXaWY4Idkn5SFO9yLHeJUuCDsOP9AgDPF+14E6tafXlGRVPizLht55NoEqohlOfW6gO3pMnIqGiV3a/Wc6vtlMI4dRtsFxURwS9eE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZBIUPN88; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZBIUPN88" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E65B8C433F1; Sun, 24 Mar 2024 22:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320011; bh=r+eUaeSBbJITi10eWBdwYxrKWd/L8nsqR8864q3AH38=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZBIUPN88vbzGf+jzen+vqUaRdWRqDwfVCuIfJ9YAYzUjmcO5jEUHgojcIGKq2Rg9x BQOi8SbJBcvDlD4kRdjg2oUGoZnpJ9xgwZYdvPvMw9MUN4RLRB+UNU96ixX0AW6VdS SuV6Kks/vBlm14aB9Kz5eC4/Sp0Noib/3SxMvH4AEqMWxOok/9XTdGfqUS6wrmRr1P Nv9or+K/0vdSrZt7vzg5STwx4mfPSWecy7osUYlksa6y0mPIgvRmPcfSE6Y/uKrNC+ a5yuew0h5HW59bgD1XrE9C7o/D1gUDRF5a3a9HbIV3IEhHkSxGSCBZ4EdVPLNcRtQx kj2pd4NJyrLHQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , syzbot+8cd36f6b65f3cafd400a@syzkaller.appspotmail.com, Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 319/715] bpf: Fix DEVMAP_HASH overflow check on 32-bit arches Date: Sun, 24 Mar 2024 18:28:18 -0400 Message-ID: <20240324223455.1342824-320-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit From: Toke Høiland-Jørgensen [ Upstream commit 281d464a34f540de166cee74b723e97ac2515ec3 ] The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index") Link: https://lore.kernel.org/r/000000000000ed666a0611af6818@google.com Reported-and-tested-by: syzbot+8cd36f6b65f3cafd400a@syzkaller.appspotmail.com Signed-off-by: Toke Høiland-Jørgensen Message-ID: <20240307120340.99577-2-toke@redhat.com> Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin --- kernel/bpf/devmap.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c index a936c704d4e77..4e2cdbb5629f2 100644 --- a/kernel/bpf/devmap.c +++ b/kernel/bpf/devmap.c @@ -130,13 +130,14 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr) bpf_map_init_from_attr(&dtab->map, attr); if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) { - dtab->n_buckets = roundup_pow_of_two(dtab->map.max_entries); - - if (!dtab->n_buckets) /* Overflow check */ + /* hash table size must be power of 2; roundup_pow_of_two() can + * overflow into UB on 32-bit arches, so check that first + */ + if (dtab->map.max_entries > 1UL << 31) return -EINVAL; - } - if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) { + dtab->n_buckets = roundup_pow_of_two(dtab->map.max_entries); + dtab->dev_index_head = dev_map_create_hash(dtab->n_buckets, dtab->map.numa_node); if (!dtab->dev_index_head) -- 2.43.0