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 91C7C31759; Tue, 16 Jan 2024 19:44:47 +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=1705434287; cv=none; b=NsQn8n+znTVfU6Lcyc9a+xZ1yyolqeubgIbEJBCFFUspND9dvEff4trLex82kNWnY+0VWtbIXL3CGkFMoypj0WvWw9olV4blnkpKsgnPVYDXq3kWdhybc8euwFIVUU3SIvyjYthOAnxshtWpt+u8DOnZKBaKwbERJPcmppWrnK0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705434287; c=relaxed/simple; bh=jEaGfXRPQAFhrnHEmaoRvwEZ/hzyFnaA7pUDoCHjSRk=; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID: X-Mailer:In-Reply-To:References:MIME-Version:X-stable: X-Patchwork-Hint:X-stable-base:Content-Transfer-Encoding; b=BY7rzCtVefnuLuxl7RWsApoAN2h4QZDSLQ8DJfYQhdQ1YJNMusVwzyhfBbO6kr5W60cMdPH8LNf9DyBD9KpYnOaH+MhlNOspQzNkOErWbJThm5Oz1+6kcyfZbGKLcZ+IsEdk5t4mwNuYooQxu3Xg3TLfOCwbZg18xx7Kz2H/DSw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dKKf+SbQ; 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="dKKf+SbQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FB96C433F1; Tue, 16 Jan 2024 19:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705434287; bh=jEaGfXRPQAFhrnHEmaoRvwEZ/hzyFnaA7pUDoCHjSRk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dKKf+SbQqAJXiqo8Q33Lo0eGoaheJzuSCCPxDPhhglXCWrEyNqUYa6WILMYExbQBq XJ9C5ak+RI/k8GRBgNGBmUkof8t9T3QMkLuuwkeTrzAujSc8M2XAchU8l9yjbm5wxi 2Hni7sToFO+6AJ6H8WdX8wth6vFeMTg2kX9Jc30ITdi4LB4jRBdEeq13UNA0xQuj9U ke9GUh/aX05wHIWHKDrNy+vMy3Di43tlBNkK3lFxj5cDXxNBRzai4o8bnErCG9dKlT 7cXjm5Mk0e626s153nDt3iZFH1izqkTdOfJCGsK+gYkxS0HHcDaFZ6Yh8RYQ9Fq7A+ Ku3YhYhAMRe2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrei Matei , Andrii Nakryiko , Andrii Nakryiko , Sasha Levin , ast@kernel.org, daniel@iogearbox.net, bpf@vger.kernel.org Subject: [PATCH AUTOSEL 6.7 051/108] bpf: Guard stack limits against 32bit overflow Date: Tue, 16 Jan 2024 14:39:17 -0500 Message-ID: <20240116194225.250921-51-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240116194225.250921-1-sashal@kernel.org> References: <20240116194225.250921-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.7 Content-Transfer-Encoding: 8bit From: Andrei Matei [ Upstream commit 1d38a9ee81570c4bd61f557832dead4d6f816760 ] This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904 Reported-by: Andrii Nakryiko Signed-off-by: Andrei Matei Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20231207041150.229139-4-andreimatei1@gmail.com Signed-off-by: Sasha Levin --- kernel/bpf/verifier.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index af2819d5c8ee..6219ab8dca5f 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -6761,7 +6761,7 @@ static int check_ptr_to_map_access(struct bpf_verifier_env *env, * The minimum valid offset is -MAX_BPF_STACK for writes, and * -state->allocated_stack for reads. */ -static int check_stack_slot_within_bounds(int off, +static int check_stack_slot_within_bounds(s64 off, struct bpf_func_state *state, enum bpf_access_type t) { @@ -6790,7 +6790,7 @@ static int check_stack_access_within_bounds( struct bpf_reg_state *regs = cur_regs(env); struct bpf_reg_state *reg = regs + regno; struct bpf_func_state *state = func(env, reg); - int min_off, max_off; + s64 min_off, max_off; int err; char *err_extra; @@ -6803,7 +6803,7 @@ static int check_stack_access_within_bounds( err_extra = " write to"; if (tnum_is_const(reg->var_off)) { - min_off = reg->var_off.value + off; + min_off = (s64)reg->var_off.value + off; if (access_size > 0) max_off = min_off + access_size - 1; else -- 2.43.0