Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1163628ybp; Wed, 9 Oct 2019 09:42:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqw/iO0Nc0dAPWRheZ4x0681jUsRCAd0EMRWChYx14e+SHfdQGQTRfFDXYk0xnHPaDOYw8t5 X-Received: by 2002:a17:906:d214:: with SMTP id w20mr3698489ejz.68.1570639330891; Wed, 09 Oct 2019 09:42:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570639330; cv=none; d=google.com; s=arc-20160816; b=v9fWTT/HeKclDjAeQrtZOFxFSrOrqD8OQiY7dDJx90P3irnyZFNejyz9vabsd/oAy9 QCMBoqKLxN9Oz6J+z2FS7UuFpNZaFTi+/+xmYdJ3VcKFyHNP5IGD69CNAoLk2pzlufjR qFp2ju2b8t6aSkQ099IryBhkX2p6EwgiXKLKhCRTq5n/4jQctl7tBF+g0FpzXPkmcJuD xSXti+SdRxN4gom3bz2/gf5RvG8y3/epDN29gfSkQE9nRb/BSXjfBb4dmi9p+GyEi9Cq qJwz1hNQetZ6Fno4VpN7eizaGhTPF+MNRJiaNKTJzz2jaR0pDJgHUvXtoDneSeOo/440 6NdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=v7hBKf1GEhdFE49Funo1lIcwwqP05a3CcKDL52mWy9g=; b=zGm0P4lLryf5bCnvgPL/AydqRxzFtp0naTNZ9eYffh79X/ZyIX3SpTzY9r1GZRuApQ y+VNswoiG1iOCRM6LIYgUvB9vqGDb20YiWNjUgv/jBwM/xSqPlnK9ImgIetJQMpaMGNu qLFo5Lh+WiYR8awNcNN8dxHyoavydkzYh8A6VvYv58MX5v3QS17dJAxhHFXIGbze0GSG wla/7rs/11lgdqI/DVhlBM1mN2APYPWyHYMr/cpBECHg3ehIOYwQpIO9hIqbF6WB1a9S AoomlqrUQ1rULaFMr8itrV1g2SKLvvEE4xnR5sIB6vcRztsQOuVnNmru8v5xzUNbJZht 45Kw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21si1605903edg.339.2019.10.09.09.41.46; Wed, 09 Oct 2019 09:42:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731843AbfJIQkB (ORCPT + 99 others); Wed, 9 Oct 2019 12:40:01 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:51607 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731173AbfJIQkA (ORCPT ); Wed, 9 Oct 2019 12:40:00 -0400 Received: from [192.168.1.110] (238.210.broadband10.iol.cz [90.177.210.238]) (Authenticated sender: i.maximets@ovn.org) by relay12.mail.gandi.net (Postfix) with ESMTPSA id EF9A3200010; Wed, 9 Oct 2019 16:39:56 +0000 (UTC) Subject: Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt To: Andrii Nakryiko , Ilya Maximets Cc: Networking , bpf , open list , Alexei Starovoitov , Daniel Borkmann , "David S . Miller" , Jonathan Lemon References: <20191009154238.15410-1-i.maximets@ovn.org> From: Ilya Maximets Message-ID: <6c1b8c0f-c317-e59e-de02-9b0afc2cb9a0@ovn.org> Date: Wed, 9 Oct 2019 18:39:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.10.2019 18:29, Andrii Nakryiko wrote: > On Wed, Oct 9, 2019 at 8:43 AM Ilya Maximets wrote: >> >> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes >> valgrind complain about passing uninitialized stack memory to the >> syscall: >> >> Syscall param socketcall.setsockopt() points to uninitialised byte(s) >> at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so) >> by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172) >> Uninitialised value was created by a stack allocation >> at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140) >> >> Padding bytes appeared after introducing of a new 'flags' field. >> >> Fixes: 10d30e301732 ("libbpf: add flags to umem config") >> Signed-off-by: Ilya Maximets >> --- >> tools/lib/bpf/xsk.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c >> index a902838f9fcc..26d9db783560 100644 >> --- a/tools/lib/bpf/xsk.c >> +++ b/tools/lib/bpf/xsk.c >> @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area, >> const struct xsk_umem_config *usr_config) >> { >> struct xdp_mmap_offsets off; >> - struct xdp_umem_reg mr; >> + struct xdp_umem_reg mr = {}; > > well, guess what, even with this explicit initialization, padding is > not guaranteed to be initialized (and it's sometimes is not in > practice, I ran into such problems), only since C11 standard it is > specified that padding is also zero-initialized. You have to do memset > to 0. OK. Sure. I'll send v2. > >> struct xsk_umem *umem; >> socklen_t optlen; >> void *map; >> -- >> 2.17.1 >>