Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp735691pxb; Thu, 5 Nov 2020 11:33:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJzrDP96KfgcIGdJeYDII3sAtUN3blyuDSQ9woX3XqPCGCJSW57Inm9jPc/Q1U1nL9mqjdkG X-Received: by 2002:aa7:d407:: with SMTP id z7mr4375012edq.234.1604604789190; Thu, 05 Nov 2020 11:33:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604604789; cv=none; d=google.com; s=arc-20160816; b=hfNMLkLvSKzmw4yejnLnQqKdOrRB8AOmF6pJblYytWhjuhszVhSwgde4guvi1AiVOK gmUA0SOBtnK6pI0pN/5nGovywF6r2R1uW2zH6VwEGnbCZuy7JeAM9+LrgoUrFO0eUK+S eb4RoWZN8ukLxJVR45Ro6G/LHDk6hORDqgDX3WLtYOJpdRgP7/uZvUhLcVVEeUYPfYiE NSjQ18Y8TG+Af85YysctezY1FF3XF5WzixlX8YDsZCXjcInrOHU/C0vikYyizs4lF0QK s8JpwPRGBO/9RDt+oqTu/eGnxd/7ArZU9Sw4UsLV+Vu+gxCHMdj6ub9uU0LJvwSoudW7 6aEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:message-id:date:to:from:subject:cc :content-transfer-encoding:mime-version:dkim-signature :dkim-signature; bh=ehC9x8cE+ZGBKrcoBMypR8Z8YvOTab6tJ2SFOzXL27c=; b=p71nOr1DIzDDAR5IcUGOyJkQgSJvsNpvrUreiMDy4d2sAexuIETgYIMThXPfTxGSe4 9EBWE0Z9J0OFVddeZUTG2mixRPb9GehDPTiCirtuZd2O1er8BniN9ytTmm74s++71ASr 1WWjlpa+dHraQ7bvNFtyOm4HgeGzOgRlklvlMAZxrpwHXPzA+Jbk02XKdeHqYg7wDmm3 w3I/8vDZ9mbf2LLfa2ifQzFoQLp37grq6nGXLL3C6Q9rYWDX132/QnYnLnXj3rkKZSB4 GQY4W9Cny795XSA6ti09IuoJiDIJ1Wgawa5nWxTQRl0/jHSRSJUhZA3MkLfpSeMYJXJh s9eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm1 header.b=buYHyesk; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=IwHq6wkE; 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 h16si1864886ejd.579.2020.11.05.11.32.46; Thu, 05 Nov 2020 11:33:09 -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=fm1 header.b=buYHyesk; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=IwHq6wkE; 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 S1727017AbgKET2a (ORCPT + 99 others); Thu, 5 Nov 2020 14:28:30 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:50283 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727851AbgKET23 (ORCPT ); Thu, 5 Nov 2020 14:28:29 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 31C695C019E; Thu, 5 Nov 2020 14:28:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 05 Nov 2020 14:28:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= mime-version:content-transfer-encoding:content-type:cc:subject :from:to:date:message-id:in-reply-to; s=fm1; bh=ehC9x8cE+ZGBKrco BMypR8Z8YvOTab6tJ2SFOzXL27c=; b=buYHyesk/b1Nhdb3//UKsAarJZURlfHZ F/wV+7xwvlPad2CqI+XXEJnwDwSfBbfK2clyrsERL8ja10WrEXyyxd98z8s1Mxot Vu+59CRVUrfL7JW0TBVtsIXlrxz0uimzHQvG+V3SyJ637ixDFLGGTtFyDj+KipWz AliPeqzttPrA46IfN258rVjpBByFqIS3Ve6mk6Mqo7WKj0T6i/IqiEZt/vaSEiXO FV46HiL89z2Ctv8MmL0kKK0UxOodkkG/bOQ8Kx+6HnhJLj6s6OpEj37pjGQCwuBd F1sE/Sx518OcZf5sbjfPPyuEfrcJE0vuXJmdKN5tL9TzgqdLjpndgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ehC9x8cE+ZGBKrcoBMypR8Z8YvOTab6tJ2SFOzXL27c=; b=IwHq6wkE aW6yx9Kk0ROQy4/bAVB7oW7ygq4wCpa49jISgt1REXVjVtDAnAaHGLU+OHkHmQyA aaEsKYOAkeWYdHHghbztFpegJxbeRVv8OHVnUouiaWV2kVrOGYCKzWfgsVICO1uD NOZ0U3DeTuYmt0+R70PQ5ryPgIZqP3XNOqSRhtWbiLULcaHJzOsMgpaOeO0l3vJC oC1BEAubWbEMw2MVtnkjy9avgEcvv60tAXDA6F2Y7PAy7JN78Eaz0NcGWfj37H5I cA5tfRw/BPm8x6WFUzyT825hBv4/cE54bUZpwyeqdeGQii2kddAqOKWt6cIRkZLy P0AjlnqCUwATUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtjedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculdejtddmnecujfgurhepggfgtgfuhffvfffkjgesthhqredttddt jeenucfhrhhomhepfdffrghnihgvlhcuighufdcuoegugihusegugihuuhhurdighiiiqe enucggtffrrghtthgvrhhnpeejfefhudeffefhjedvvefhheduledtueejvedugedvjedv jeeljefggedtjeejveenucfkphepieelrddukedurddutdehrdeigeenucevlhhushhtvg hrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegugihusegugihuuhhurdig hiii X-ME-Proxy: Received: from localhost (c-69-181-105-64.hsd1.ca.comcast.net [69.181.105.64]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F22D3060060; Thu, 5 Nov 2020 14:28:27 -0500 (EST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: "bpf" , "linux-kernel@vger.kernel.org" , "ast@kernel.org" , "daniel@iogearbox.net" , "Kernel Team" Subject: Re: [PATCH bpf v2 1/2] lib/strncpy_from_user.c: Don't overcopy bytes after NUL terminator From: "Daniel Xu" To: "Song Liu" Date: Thu, 05 Nov 2020 11:28:11 -0800 Message-Id: In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu Nov 5, 2020 at 10:16 AM PST, Song Liu wrote: > > > > On Nov 4, 2020, at 6:25 PM, Daniel Xu wrote: > >=20 > > do_strncpy_from_user() may copy some extra bytes after the NUL > > We have multiple use of "NUL" here, should be "NULL"? > > > terminator into the destination buffer. This usually does not matter fo= r > > normal string operations. However, when BPF programs key BPF maps with > > strings, this matters a lot. > >=20 > > 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. > >=20 > > 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. > >=20 > > This commit uses the proper word-at-a-time APIs to avoid overcopying. > >=20 > > 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, 7 insertions(+), 2 deletions(-) > >=20 > > diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c > > index e6d5fcc2cdf3..d084189eb05c 100644 > > --- a/lib/strncpy_from_user.c > > +++ b/lib/strncpy_from_user.c > > @@ -35,17 +35,22 @@ static inline long do_strncpy_from_user(char *dst, = const char __user *src, > > goto byte_at_a_time; > >=20 > > while (max >=3D sizeof(unsigned long)) { > > - unsigned long c, data; > > + unsigned long c, data, mask, *out; > >=20 > > /* 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)= ; > >=20 > > - *(unsigned long *)(dst+res) =3D c; > > if (has_zero(c, &data, &constants)) { > > data =3D prep_zero_mask(c, data, &constants); > > data =3D create_zero_mask(data); > > + mask =3D zero_bytemask(data); > > + out =3D (unsigned long *)(dst+res); > > + *out =3D (*out & ~mask) | (c & mask); > > return res + find_zero(data); > > + } else { > > This else clause is not needed, as we return in the if clause. Thanks, will change in v3. [..]