Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp814715pxb; Wed, 11 Nov 2020 17:36:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxhCUyBT/HH9sXj/y4AZtGqKAkx0cBUTEujqKX7ml++CQEq0qMol2G9PR6jDSBfCbwlOSE8 X-Received: by 2002:a50:bb66:: with SMTP id y93mr2645484ede.244.1605145016737; Wed, 11 Nov 2020 17:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605145016; cv=none; d=google.com; s=arc-20160816; b=NdgzM55frjnYw5htTovjR88iIjoh3/ezWqal2vqo4a30M7WDwzARD96UBVS2+6mEx5 f00PhAfGTTnxXv9cIAXa/0mu19Hw7j+y+piDwWNRI8XB/EDrlACN5CR1k0yQNHPtQKo7 pybL3/pTFyNpoolEWN0IWh57M0Oc0mHC8u5h6+NFFgVnYdyFNIp0S8KtzPRzQmTmyUdp KLqKu9EZeOESocbm7pSLgszRs+f+J9guLGCMYgZ2uF6qSKcC+DEv5joFN76Gm0m+VSYB 4e7H1wQawJ87xz9GkOHxoWQGNX9YdFJOu2XB8I+Tfv+4orXm6dw5UTIpe9SEn6fzHQdH 8JPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=JB1VBqITSKhPXsfUHzxUXkMo7GYuI0H/W3InHGhrcyk=; b=TYU1F2Bo3/kbY9K5JcxsPXnUxwoJuWlmbjNybLIXBHubt4bpIdWzxakHyv+xFSRdii g+B+Ef3zlaHJzPjLrgJ4cqzOHN3snTEKus/ZWHlTcsOWuJKdxnIlJ2n4bU0d4OPiXuiw lJeOU61MPNMgkhSDAyKQi4iuSLX/sSc8IyQ/xkaLnTuIVx5ME0J/ak6dIUG7BT1DMHs1 3Gp+cEEzh/bc0rTthTonjVDUougpF9f33QFw7rQw1bcO1+9JSXlXV1xrVhh96aEhm9Yb sWfAJdmQo700CnxKBsK1WqN2tGByOwTPqB/xDVyFMUX/3VgAuOjMUlpRFhqHCg7O31Z2 qeIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=FZqM56GK; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Y7iH9vFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t12si3988767edc.181.2020.11.11.17.36.05; Wed, 11 Nov 2020 17:36:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=FZqM56GK; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Y7iH9vFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728392AbgKLBc1 (ORCPT + 99 others); Wed, 11 Nov 2020 20:32:27 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:41073 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726970AbgKKWqh (ORCPT ); Wed, 11 Nov 2020 17:46:37 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 198FB638; Wed, 11 Nov 2020 17:46:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 11 Nov 2020 17:46:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm2; bh=JB1VBqITSKhPX sfUHzxUXkMo7GYuI0H/W3InHGhrcyk=; b=FZqM56GKkg2GCPlbMg3q8u+T9Az+t gpirqbGJBKtYgwu1V51EYkZcjDMQalXcufXU1zD8S2GJbbv06JXWvv4OrEwMgxpu cJlX5oxhpLzBrB2FC+WEfP+uYww3RhFcUX5oh4LZxXbBADpMuOfF1l3/H9fhhkYU RSg6RHDK3yVM659FSxEeh6S7KfyzvfHeooS3UvEXE9nwM3WugIwYxrjDqjFxTrKF 1bMQs6/Zel4vDnD4d5iOHWnADyxwnB46nPN+0Xa9POFKoDOg5MomazLhVUx9YXFm aq7xjaowxPB66KrEyYCiuRcT3rThngwNaTJnKmqhfUdbFufR2OcyqrQsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=JB1VBqITSKhPXsfUHzxUXkMo7GYuI0H/W3InHGhrcyk=; b=Y7iH9vFS tpwfKsdEayadu45on3j5hG/YDoswnVmEGzG2NXWEEdxhLUb52mhgNXlCFBgpiZE/ Fa5wVnmgZiFo339m/EVuubuOjtNFmbz29Z2pUFYF4+VyGUMDJ//3KwV+mtkKpa2C xLnnqcI+cg90pblb2vfqwUxf1SJwelAig/jTlYAzjkynkzNa1TpeuLT9RV0K8gkn EIhCEJ725OobPC/siONBU77D6rcXLpbnJuVaGWYJj6E0DIlwW+k8n3B6t+acnqgj HXZNXvLVXg87QI5Wd4OhxtwPTGLdivk5/KEBfZea4GsYALbwDR1FMTCCuF0SVt+L whya2eBzv6fObQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvuddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdljedtmdenucfjughrpefhvf fufffkofgjfhgggfestdekredtredttdenucfhrhhomhepffgrnhhivghlucgiuhcuoegu gihusegugihuuhhurdighiiiqeenucggtffrrghtthgvrhhnpefgkeduleekhfetvefhge fgvdegfeejfefguedvuddthffggffhhedtueeuteefieenucfkphepieelrddukedurddu tdehrdeigeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegugihusegugihuuhhurdighiii X-ME-Proxy: Received: from localhost.localdomain (c-69-181-105-64.hsd1.ca.comcast.net [69.181.105.64]) by mail.messagingengine.com (Postfix) with ESMTPA id B61CC3063080; Wed, 11 Nov 2020 17:46:34 -0500 (EST) From: Daniel Xu To: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, songliubraving@fb.com, andrii.nakryiko@gmail.com Cc: Daniel Xu , kernel-team@fb.com Subject: [PATCH bpf v5 1/2] lib/strncpy_from_user.c: Don't overcopy bytes after NUL terminator Date: Wed, 11 Nov 2020 14:45:54 -0800 Message-Id: X-Mailer: git-send-email 2.29.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org do_strncpy_from_user() may copy some extra bytes after the NUL terminator into the destination buffer. This usually does not matter for normal string operations. However, when BPF programs key BPF maps with strings, this matters a lot. A BPF program may read strings from user memory by calling the bpf_probe_read_user_str() helper which eventually calls do_strncpy_from_user(). The program can then key a map with the resulting string. BPF map keys are fixed-width and string-agnostic, meaning that map keys are treated as a set of bytes. The issue is when do_strncpy_from_user() overcopies bytes after the NUL terminator, it can result in seemingly identical strings occupying multiple slots in a BPF map. This behavior is subtle and totally unexpected by the user. This commit has strncpy start copying a byte at a time if a NUL is spotted. Fixes: 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers") Signed-off-by: Daniel Xu --- lib/strncpy_from_user.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c index e6d5fcc2cdf3..83180742e729 100644 --- a/lib/strncpy_from_user.c +++ b/lib/strncpy_from_user.c @@ -40,12 +40,11 @@ static inline long do_strncpy_from_user(char *dst, const char __user *src, /* Fall back to byte-at-a-time if we get a page fault */ unsafe_get_user(c, (unsigned long __user *)(src+res), byte_at_a_time); + if (has_zero(c, &data, &constants)) + goto byte_at_a_time; + *(unsigned long *)(dst+res) = c; - if (has_zero(c, &data, &constants)) { - data = prep_zero_mask(c, data, &constants); - data = create_zero_mask(data); - return res + find_zero(data); - } + res += sizeof(unsigned long); max -= sizeof(unsigned long); } -- 2.29.2