Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3597202pxb; Mon, 24 Jan 2022 13:09:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5yBDClmRzJUQkwCnKL/mfhaDi8jyjp1YYLJnoy/RWKIDJpmPPbEwimBEuw6xqrB8BFtzN X-Received: by 2002:a63:7c03:: with SMTP id x3mr12926503pgc.433.1643058542301; Mon, 24 Jan 2022 13:09:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643058542; cv=none; d=google.com; s=arc-20160816; b=dnYHWDLajbwYX+xitgmG+/e+x1AC1UphNXT9MentVccVnKMkZ3IURyQ0maIjJ+Q4Bb llR7av9ydquJJd7ikH77cgnGX1Pa3D0dPWA5a1p+u6Lu/o7GqC72dglUFLeius3eZdOK elqXHGZExJ6qhmsMkVxU0LaXm8dwYh4OtompUpi/pkA3XhdnosjhSny9zGLOWBx7X/4D fE+9j6DuZ7gLjvG2b80p1trHFrbzTGW2mONcC5n4blhM+CdvPw7Yoq8T596mae0eFiHO zEvyYC8C397TYkQRklbNgD3+MA4FPDxr3SrKuG8hSVhsRR/7vuj97EslFLpRZRe+Ah7Y tMvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=gC6uQMiB2UYXAnAX124HkmXnb86ExhFUgDuKgEhconw=; b=qmJrAISk0oVqqBGNNKZejWYUHKT6mV9LoSfa4b6DIFJhUAtkPQs22+rQ07XDYTETqU CZG5fswJDHh4dZc8JPWsLqTlmXxB7HXjpqZTkPHJq3Emm1nOkaoJSJGV3ZGkROdxADvv 5FeBdWA8W1tZQjN/F7nWtGo+LfuuH/cCL6+T/16OnKf+Wqb3MKu083BebXNNWoQRcjcx +GgQiHk590JbIfHVWcZzuwOLSFRiC3abdpeUz1g8SGEaVTiztkvJ1IP4o6ijCXg+WvmM x4N9FBb4JHYVDK96J+dkr+s5RJFDER5cPlZRr0OGqyZ/3T2VzRU7rZXkySilplvdGnG3 AqQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RUtVEXsE; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gf15si332328pjb.90.2022.01.24.13.08.50; Mon, 24 Jan 2022 13:09:02 -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=@linuxfoundation.org header.s=korg header.b=RUtVEXsE; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357477AbiAXUd5 (ORCPT + 99 others); Mon, 24 Jan 2022 15:33:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355424AbiAXUNj (ORCPT ); Mon, 24 Jan 2022 15:13:39 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 135B1C061768; Mon, 24 Jan 2022 11:36:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D02ACB81239; Mon, 24 Jan 2022 19:36:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0835DC340E5; Mon, 24 Jan 2022 19:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643052959; bh=Fu2rLzeUDaVElkoc6+b62pdiMdE6f0wRxHkWDfpMuv4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RUtVEXsEdZ/1gbxOTVxDRJjg10Gpy31EGE5qN6Ib4d7OsqR7BPE7i5fOCJkVB2cB6 eguJpOc6N8/aAZDfd1YjSqwiWamYs6d5+cpmDfld9pK2iE9UPavGXc+cunvInh0lPi IugevJAdI7peSQMRzxVwl+IvqmRo+TRUwz7sySwA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heiner Kallweit , Jean Delvare , Wolfram Sang , Sasha Levin Subject: [PATCH 5.4 229/320] i2c: i801: Dont silently correct invalid transfer size Date: Mon, 24 Jan 2022 19:43:33 +0100 Message-Id: <20220124184001.775036885@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124183953.750177707@linuxfoundation.org> References: <20220124183953.750177707@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Heiner Kallweit [ Upstream commit effa453168a7eeb8a562ff4edc1dbf9067360a61 ] If an invalid block size is provided, reject it instead of silently changing it to a supported value. Especially critical I see the case of a write transfer with block length 0. In this case we have no guarantee that the byte we would write is valid. When silently reducing a read to 32 bytes then we don't return an error and the caller may falsely assume that we returned the full requested data. If this change should break any (broken) caller, then I think we should fix the caller. Signed-off-by: Heiner Kallweit Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin --- drivers/i2c/busses/i2c-i801.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c index a959062ded4f8..4e6d0b722ddcd 100644 --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -785,6 +785,11 @@ static int i801_block_transaction(struct i801_priv *priv, int result = 0; unsigned char hostc; + if (read_write == I2C_SMBUS_READ && command == I2C_SMBUS_BLOCK_DATA) + data->block[0] = I2C_SMBUS_BLOCK_MAX; + else if (data->block[0] < 1 || data->block[0] > I2C_SMBUS_BLOCK_MAX) + return -EPROTO; + if (command == I2C_SMBUS_I2C_BLOCK_DATA) { if (read_write == I2C_SMBUS_WRITE) { /* set I2C_EN bit in configuration register */ @@ -798,16 +803,6 @@ static int i801_block_transaction(struct i801_priv *priv, } } - if (read_write == I2C_SMBUS_WRITE - || command == I2C_SMBUS_I2C_BLOCK_DATA) { - if (data->block[0] < 1) - data->block[0] = 1; - if (data->block[0] > I2C_SMBUS_BLOCK_MAX) - data->block[0] = I2C_SMBUS_BLOCK_MAX; - } else { - data->block[0] = 32; /* max for SMBus block reads */ - } - /* Experience has shown that the block buffer can only be used for SMBus (not I2C) block transactions, even though the datasheet doesn't mention this limitation. */ -- 2.34.1