Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp612062pxb; Thu, 20 Jan 2022 22:03:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJymjZeNt/dMuPjqcBy+bPTcLkCWruzhnis9Y2AxqZr2qlBsN1TXYEVuHNoUjz7U3GKTtDvt X-Received: by 2002:a17:903:32cd:b0:14b:872:788c with SMTP id i13-20020a17090332cd00b0014b0872788cmr2821614plr.156.1642745010116; Thu, 20 Jan 2022 22:03:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642745010; cv=none; d=google.com; s=arc-20160816; b=ZDqF4k3c3OAjWX0mSRwXh2bEGfZDGgfYF5KKL9yaeJ1udZlJyiuNc3IbSqBOLg2o1t 51tc661XbI4ofTuX8if10mGLcLyas/Ej6g1q1AcMssGYHrWTxCquAA4Bh2eumN3ONqTF SvxzKk+Munvh5HbJvzfxHDG0Rvnw4OZN1f4UHcwpAA5Wzn7UFM4oB1dT7wMRXYYebZZO 9a7JW/RB7b0lKib0zeqx7tCPC/03EZaTAjynrztvvBtUxwnjcLMIGx9+2AR/NYKxAarU AYQKn8qjFXJ1Fl3EW3bciO66zDsJlFPqEnfgmTkMZbCnUu9t61zphZLCzyupRdlXVyzj XygA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tLdog0n5L37y3MRWMAFNB4F/ux6HarIU0b+GSL5AL8I=; b=P7PDMWGPgb7s4WMdY+QbiBuTfCN3bntWIl4duROPyGDCf7iabtazwWqZqASwBKcLPh klsG+8EAl3e2Ts9LvwQMqvxlWU1rTmd/lEm5qxy52xpy6KZc53l6tuR+ZrxdmmuYMDCo etGXkGf4El/eLO+AeRh8b7G+MgHR8Tu7FxRwXCee7GekstM9mwkYuAsGDQRxEBLEU5MG kbXxHcHLqkLIOO+kWNn1w2Ti5mR0hmTZw2G+EcYaM+SLPx6VIgP+6G479iTaJ1Ft19ZY 09pMq/O/nH/voHLqkd/kAxo3jORN8+nTT+0zoI+V3yrC1RB23z0Daw60V57EOtUf9af4 X9/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=JxuUbd1e; 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 d6si5319048pgb.149.2022.01.20.22.03.18; Thu, 20 Jan 2022 22:03:30 -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=@ziepe.ca header.s=google header.b=JxuUbd1e; 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 S1348634AbiARTjf (ORCPT + 99 others); Tue, 18 Jan 2022 14:39:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245123AbiARTje (ORCPT ); Tue, 18 Jan 2022 14:39:34 -0500 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E99C0C06161C for ; Tue, 18 Jan 2022 11:39:33 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id d24so218735qkk.5 for ; Tue, 18 Jan 2022 11:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tLdog0n5L37y3MRWMAFNB4F/ux6HarIU0b+GSL5AL8I=; b=JxuUbd1edEtbcMjCPSHSeTD/CMYEQdKqj/JLXxnkn+Bkc6GbozsOmUxwYRcTFsY47V WslujJVSY9vZtdXObppzaJQ0XtxjM0/O6BcKQE/zLqUnX0H8LSFwCeWeCMv6fVoWagiZ UtOtlLdGXjCLwzJlFu1FXI8C5OfuzJPVSSbieu+2VLq4ZVapGXxYrJTLJFqeMIFy9d2Z k0/ON6VVV5+yE9VVVEWmaWQlbwRu5BN60dy3Gg3kukxXeKDIhZdFxFaEc4FoJa1LtbHS Uv158qvrSco6aI/Rx+lCeqczh5qvcETHy05zvS+uAImu/AEx1laINzofgC3XGJBKWFzn RXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tLdog0n5L37y3MRWMAFNB4F/ux6HarIU0b+GSL5AL8I=; b=6v7CeIsUm+vCYfTAf+mG/p2bdJYT7UiSDmWzQcufb+IJN3x4IH2iSxVAVITy+YtL5f P56e/BGpQjPsH+brAwxK+wjjWSTJ+7186VktrvVlCAFTtQvongduJ7O+Uh2E2Q9c22IA qii+LO04DQht9kv4SQiChia5ri9A/g9VBaXS11tY3pVS9Se91UnjSUF29XKGhIQ5/rVX CGF0dtvK665WkdeHSku0o0NkfETu5mtEtjwJuADdaXlm0u4y5AJKagCHmJHUv9wthDP6 xCwtIIQ0ZsqXMNF7uR7F1clUSsT96AWN/sbQezDf/WZ7raDCh9tYiYm4Vr84kXyzNSGJ Mm+g== X-Gm-Message-State: AOAM530vu5yscyaFU6h5P6f9Pm3rzBG6pneVNty/9URxWQHqZvu6XKf1 WsjTcdfxNehjel4WabVunbtX3w== X-Received: by 2002:a37:de09:: with SMTP id h9mr18417793qkj.764.1642534772953; Tue, 18 Jan 2022 11:39:32 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id a19sm431977qtx.7.2022.01.18.11.39.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jan 2022 11:39:32 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1n9uKJ-0012sn-OS; Tue, 18 Jan 2022 15:39:31 -0400 Date: Tue, 18 Jan 2022 15:39:31 -0400 From: Jason Gunthorpe To: Jann Horn Cc: Kees Cook , Peter Huewe , Jarkko Sakkinen , linux-integrity@vger.kernel.org, Stefan Berger , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2] tpm: vtpm_proxy: Double-check to avoid buffer overflow Message-ID: <20220118193931.GH8034@ziepe.ca> References: <20220118183650.3386989-1-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022 at 08:32:43PM +0100, Jann Horn wrote: > On Tue, Jan 18, 2022 at 7:37 PM Kees Cook wrote: > > When building with -Warray-bounds, this warning was emitted: > > > > In function 'memset', > > inlined from 'vtpm_proxy_fops_read' at drivers/char/tpm/tpm_vtpm_proxy.c:102:2: > > ./include/linux/fortify-string.h:43:33: warning: '__builtin_memset' pointer overflow between offset 164 and size [2147483648, 4294967295] > > [-Warray-bounds] > > 43 | #define __underlying_memset __builtin_memset > > | ^ > > Can you explain what that compiler warning actually means, and which > compiler it is from? Is this from a 32-bit or a 64-bit architecture? > > It sounds like the compiler (GCC?) is hallucinating a codepath on > which "len" is guaranteed to be >=2147483648, right? Why is it doing > that? Is this some kinda side effect from the fortify code? I agree, this looks bogus, or at least the commit message neeeds alot more explaining. static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count) if (count > sizeof(proxy_dev->buffer)) [...] proxy_dev->req_len = count; Not clear how req_len can be larger than sizeof(buffer)? Jason