From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) (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 A0E8C1CEEA3 for ; Fri, 6 Sep 2024 13:56:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.133.104.62 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725630982; cv=none; b=HNwemckiacb6m5Epi17jXyLYripkmzo8ArHKGxAs2nv0aB2KDcO72EiVTYvSBC4Y446wrzx4kXi86+Gmg109LK3MrU4Q/xeoWchSoyO23A5z0MgMRVbJLO6ilHNVVoPn9YcY4h3MHZqLK/Uq3gGOQrWi2Aq+iOyxGlPf8JeoMVw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725630982; c=relaxed/simple; bh=Fgw5RC9RL2tEnxMC+WA/YKC/jIjukv7toG74PPH9jp8=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=JdQ4nziEyEAJVIECsumyBInC6t7mCvTwXUNZt+stHYuCDNQrkE56vcirq9gzA8BxApCvwr1zk5doQ86ZYBARrBBOUSw6AoTHxpmaDAYqp30+ponIsGggWBbgki0peuT8JDes1SpTO82OHmDPNr77AZyd7mTejGxNSZV3xuhIoVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=iogearbox.net; spf=pass smtp.mailfrom=iogearbox.net; dkim=pass (2048-bit key) header.d=iogearbox.net header.i=@iogearbox.net header.b=kjLyUXLr; arc=none smtp.client-ip=213.133.104.62 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=iogearbox.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iogearbox.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=iogearbox.net header.i=@iogearbox.net header.b="kjLyUXLr" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iogearbox.net; s=default2302; h=Content-Transfer-Encoding:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References; bh=Gr5jAw7OlqlGPjjaOsSHO420mza/QBCJH8hGfimTmvI=; b=kjLyUXLrUFRrd5d/p9DEu9leHq U+e3gfagihAFRuxVC4viSkRLi92S5yYeT7Mwkspr9Sd0r8ny32YjfSTyyD9riKo4c5qHIP/O7H37K xUTEn28kL0hAZI3us9m/tqM/VgSYZbxmdyxwRZcE+mlDgPmFYRX4kpyYmDG2TtubndbjHSnGdx2sM oS9Kn3TDzGcQyKurx85Ui0FWkLBdnfqUz5yUkBMEmEid3g7Ws+BzeP0yNhrEUMkM899qmhYeMT/BP m7iCrqo0Y3oTcIy46okX6N1c+UMcbwVig+MG9YbIMZQZjM9UcyYZTRM/Y0GXxHYp6gXMq5/mYhJl+ aPt5DL5A==; Received: from 15.248.197.178.dynamic.cust.swisscom.net ([178.197.248.15] helo=localhost) by www62.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smZRa-0001yi-LC; Fri, 06 Sep 2024 15:56:10 +0200 From: Daniel Borkmann To: bpf@vger.kernel.org Cc: shung-hsi.yu@suse.com, andrii@kernel.org, ast@kernel.org, kongln9170@gmail.com, Daniel Borkmann Subject: [PATCH bpf-next v4 1/8] bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit Date: Fri, 6 Sep 2024 15:56:01 +0200 Message-Id: <20240906135608.26477-1-daniel@iogearbox.net> X-Mailer: git-send-email 2.21.0 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.10/27390/Fri Sep 6 10:38:06 2024) The bpf_strtol() and bpf_strtoul() helpers are currently broken on 32bit: The argument type ARG_PTR_TO_LONG is BPF-side "long", not kernel-side "long" and therefore always considered fixed 64bit no matter if 64 or 32bit underlying architecture. This contract breaks in case of the two mentioned helpers since their BPF_CALL definition for the helpers was added with {unsigned,}long *res. Meaning, the transition from BPF-side "long" (BPF program) to kernel-side "long" (BPF helper) breaks here. Both helpers call __bpf_strtoll() with "long long" correctly, but later assigning the result into 32-bit "*(long *)" on 32bit architectures. From a BPF program point of view, this means upper bits will be seen as uninitialised. Therefore, fix both BPF_CALL signatures to {s,u}64 types to fix this situation. Now, changing also uapi/bpf.h helper documentation which generates bpf_helper_defs.h for BPF programs is tricky: Changing signatures there to __{s,u}64 would trigger compiler warnings (incompatible pointer types passing 'long *' to parameter of type '__s64 *' (aka 'long long *')) for existing BPF programs. Leaving the signatures as-is would be fine as from BPF program point of view it is still BPF-side "long" and thus equivalent to __{s,u}64 on 64 or 32bit underlying architectures. Note that bpf_strtol() and bpf_strtoul() are the only helpers with this issue. Fixes: d7a4cb9b6705 ("bpf: Introduce bpf_strtol and bpf_strtoul helpers") Reported-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/481fcec8-c12c-9abb-8ecb-76c71c009959@iogearbox.net --- v3 -> v4: - added patch kernel/bpf/helpers.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 3956be5d6440..0cf42be52890 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -518,7 +518,7 @@ static int __bpf_strtoll(const char *buf, size_t buf_len, u64 flags, } BPF_CALL_4(bpf_strtol, const char *, buf, size_t, buf_len, u64, flags, - long *, res) + s64 *, res) { long long _res; int err; @@ -543,7 +543,7 @@ const struct bpf_func_proto bpf_strtol_proto = { }; BPF_CALL_4(bpf_strtoul, const char *, buf, size_t, buf_len, u64, flags, - unsigned long *, res) + u64 *, res) { unsigned long long _res; bool is_negative; -- 2.43.0