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=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT 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 E5DB0C10F0E for ; Mon, 15 Apr 2019 10:48:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A8F3C20684 for ; Mon, 15 Apr 2019 10:48:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555325308; bh=hhB02yam6MEUn4wmFJBkaFOssDcEtnM5eNTPDh0g4oA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=CDcr5OpnufKE7DJ7rZkyc7Tp4ZF2GOXiYx0RfVzok0784Gz2vHDWCUgHfQnixbDPd ZDV9Rp8lz6l6vupc3YYDxzdHUgqAnhtPgcueY5yDEn4IuQj1nLJmqjfJLFtSgy5iLF rFVjsI70+LIsQNgtFJtRV+EgEEWDXysU1iZOJxdU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726476AbfDOKs2 (ORCPT ); Mon, 15 Apr 2019 06:48:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:51642 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727050AbfDOKs2 (ORCPT ); Mon, 15 Apr 2019 06:48:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C9E8420848; Mon, 15 Apr 2019 10:48:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555325307; bh=hhB02yam6MEUn4wmFJBkaFOssDcEtnM5eNTPDh0g4oA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wqlR6PM/3och3EkxXT+fyoqkfynJztcU35XJm73/9+z+0YjGmc3Eq8+/U73rQtyhO 5KbxHLpLP110f0K/OmCY+pkPZROYuL8966wr32tOvjJRZCNc6pyoGPWIFAJZC2ILtU FeJh/2OXqLDfloTbGJojm1jGNMaN4ELr6voy6LKE= Date: Mon, 15 Apr 2019 12:48:25 +0200 From: Greg KH To: Jarkko Sakkinen Cc: stable@vger.kernel.org, James Morris , Tomas Winkler , Jerry Snitselaar Subject: Re: [PATCH] tpm/tpm_crb: Avoid unaligned reads in crb_recv() Message-ID: <20190415104824.GB9397@kroah.com> References: <20190410135432.28684-1-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190410135432.28684-1-jarkko.sakkinen@linux.intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Apr 10, 2019 at 04:54:32PM +0300, Jarkko Sakkinen wrote: > commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream > > The current approach to read first 6 bytes from the response and then tail > of the response, can cause the 2nd memcpy_fromio() to do an unaligned read > (e.g. read 32-bit word from address aligned to a 16-bits), depending on how > memcpy_fromio() is implemented. If this happens, the read will fail and the > memory controller will fill the read with 1's. > > This was triggered by 170d13ca3a2f, which should be probably refined to > check and react to the address alignment. Before that commit, on x86 > memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right > thing (from tpm_crb's perspective) for us so far, but we should not rely on > that. Thus, it makes sense to fix this also in tpm_crb, not least because > the fix can be then backported to stable kernels and make them more robust > when compiled in differing environments. > > Cc: stable@vger.kernel.org > Cc: James Morris > Cc: Tomas Winkler > Cc: Jerry Snitselaar > Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface") > Signed-off-by: Jarkko Sakkinen > Reviewed-by: Jerry Snitselaar > Acked-by: Tomas Winkler > --- > backport v4.4.178 > drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) I need a 4.9.y version first before I can take a 4.4.y version, as we do not want anyone to have a regression moving from 4.4.y to a newer kernel. thanks, greg k-h