From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABFDCC388F2 for ; Tue, 3 Nov 2020 18:08:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 440E3221FB for ; Tue, 3 Nov 2020 18:08:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=dxuuu.xyz header.i=@dxuuu.xyz header.b="Jx/3ugQr"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="cMF5blKG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729048AbgKCSIG (ORCPT ); Tue, 3 Nov 2020 13:08:06 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:53407 "EHLO wout4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725892AbgKCSIG (ORCPT ); Tue, 3 Nov 2020 13:08:06 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D2A82F49; Tue, 3 Nov 2020 13:08:05 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 03 Nov 2020 13:08:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= mime-version:content-transfer-encoding:content-type:to:cc :subject:from:date:message-id; s=fm1; bh=rMYJLeewpKSl7PjZkUWmhWD BHM+s/h409vxsCzOPf3U=; b=Jx/3ugQrlD5yPRVFJWvcSlSSHUQrMUJ5NsaKXG+ wLlBmHAyDn+4pF/P3sNd4h3j9SaqNLyeNpVgrc29lNuDO1VaD5QJAoi2CB7e7eRH iwrVxufsyRQxztO+fnhqgThBI1g/Kf5Hg0YoqMFnlU7tg0QGx1b5IU27eZXTEsqp MtEH4AbohggHQTUaNonjS/570c44iodY4uUSHS4dnAKXZKNfHf5pEt0wt+dnJfVt UeMQxaXzIZWy4okVoqcTL81ttGJzJgztRR3Zv0s5PWHmCkNVNfqfGhAqjwE+TFka f35jrNQz9//VoyZ3HEKI49n6M2EGmP1bf8ShHSn/loFEy9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rMYJLe ewpKSl7PjZkUWmhWDBHM+s/h409vxsCzOPf3U=; b=cMF5blKGd/Ty1/b1gbAXH/ prS0Zf1GOnQHEhIfie97YG+oVadM8BK1uTNZ+nz/B/7SuDNlkB1Rw/7Dl1iAYmv7 1bfbB5iZvP+Swa6JKG7CimVzzXWlr9ZHo4rcHfrweTDWBWt4eLlVCU3btm9BrIoo Sg4lLl4VZKj6GkXoIw754O0GXIdmqsBIB2AI8duBRAaj8D3KvCoOLIyuQH7AK9k+ YKQrIR8QIu/dI2kQAkQx4XDmqzvYiW19kl9IlNEtgfQ0lpBDYR5yhKPaZ6SaPsQG NkTwqbvreLo9eFArfzWdKV8j9ueqFBzX0JJ/QR4p18yd73xhHzhVaRy5oZ6cekxg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtfedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdefhedmnecujfgurhepgg fgtgfvuffhfffksehtqhertddttdejnecuhfhrohhmpedfffgrnhhivghlucgiuhdfuceo ugiguhesugiguhhuuhdrgiihiieqnecuggftrfgrthhtvghrnhepleejkeekkeeiuedtfe dvveeuudffkedtvdegudeftdegfeevieetheduffegudfgnecuffhomhgrihhnpehgihht hhhusgdrtghomhenucfkphepieelrddukedurddutdehrdeigeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegugihusegugihuuhhurdighiii 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 B33F6306468E; Tue, 3 Nov 2020 13:08:04 -0500 (EST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 To: Cc: Subject: bpf_probe_read*str() may store junk after NUL terminator From: "Daniel Xu" Date: Tue, 03 Nov 2020 09:45:41 -0800 Message-Id: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Hi, I recently received a bpftrace bug report [0] that identical strings were being stored as separate entries in maps. I dug into the issue and it turns out that bpf_probe_read*str() may store junk after the NUL terminator due to how do_strncpy_from_user() does long-sized copies. Here is the code in question from lib/strncpy_from_user.c: *(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); return res + find_zero(data); } This behavior is likely to cause subtle issues in bpf programs so a kernel fix may be necessary. Here is a quick reproducer: str_trailing_bytes.c: #include #include #include const char s[] =3D "mestring"; __attribute__((noinline)) void function1(char *first __attribute__((unu= sed)), char *second __attribute__((unused))) { } int main(int argc __attribute__((unused)), char **argv __attribute__((u= nused))) { char *first =3D malloc(64 * sizeof(char)); char *second =3D malloc(64 * sizeof(char)); // Make sure bytes after the first string are 0s memset(first, 0, 64 * sizeof(char)); memcpy(first, s, sizeof(s)); // Make sure bytes after second string are 1s memset(second, 1, 64 * sizeof(char)); memcpy(second, s, sizeof(s)); function1(first, second); free(first); free(second); return 0; } # bpftrace -e \ 'uprobe:./str_trailing_bytes:function1 { @[str(arg0)] =3D count(); @[str(= arg1)] =3D count(); exit() }' \=20 -c ./str_trailing_bytes Attaching 1 probe... @[mestring]: 1 @[mestring]: 1 Thanks, Daniel [0]: https://github.com/iovisor/bpftrace/pull/1586/