Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp574659ybt; Fri, 26 Jun 2020 06:34:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywW8G8CFVzKKkuXodVx8eEj5JTkTvaO9ii69zhWFMB6jdJf6S5FEeGO6wIY/oJ6hJmDkCG X-Received: by 2002:a50:cd1e:: with SMTP id z30mr3298382edi.364.1593178498661; Fri, 26 Jun 2020 06:34:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593178498; cv=none; d=google.com; s=arc-20160816; b=Eju1a41z1rHN5Q1bexLU5VtjnvkiWxPX9L4GxQGkReCr2HJyP8ndNSUFMVAgtfWmec 0pxw75qOB4nXErR0e9r/hxHwjgwoUm/ruwUKoYmnap33mOhUfKlem3dblyzbukXHJpBw kOx03t2bvayTU1Vt7nZ1qrmhcadtA2FEDCrzZ52sWTToYGkw76ELzf4DSkD7FA1+v82s Fg+e57J1TDXa6teCeoSW5JUoBTu/LAqJmvkrzs2wwoBjiXwfarDMS0amXRp5KUvzVCEj P1ByC5IUAqZKvUbphgUDJ50WtM76sxQRGKyfK7g6L75Hxjm5DzT2d9rAv6HljUSGMzd4 uldw== 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:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=AcYxduPCwUaHT7XT1yviRFedtezAPWPOde4MXvBxHrA=; b=gmudvCouL4s6Re6fTkIYY15T69v94w2hx2yHx4PwJt3KHP4F8PlYchwBLxeKfIzgon HnBrahDxx1IaZCXNYfJovJ7y3OZlVUcrKDGTGpwgV8/koczatgbRZ71r4eriBO7UQSiB 92ohnzbV1ivck5O+SorGx+ogiaqWelBZgCBT+5hAzwfgBPIfpyImwWCGn7SOfoSyHHao nY0h2am+EGP7Geau+ujk5G0t7qcnWydfBK6/DuE94mnYrLxYrZubeJvflkdR/mvCaoKu z5OTJbOTP+0fqvpIqSKbHcN8aHFjhvWOU+I5pzWjbOv7+4ykNbTMpy0VGV7O9wb01BIk q+uA== ARC-Authentication-Results: i=1; mx.google.com; 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 y6si449951edp.197.2020.06.26.06.34.34; Fri, 26 Jun 2020 06:34:58 -0700 (PDT) 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; 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 S1728313AbgFZNd4 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 26 Jun 2020 09:33:56 -0400 Received: from unicorn.mansr.com ([81.2.72.234]:40838 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbgFZNdz (ORCPT ); Fri, 26 Jun 2020 09:33:55 -0400 X-Greylist: delayed 986 seconds by postgrey-1.27 at vger.kernel.org; Fri, 26 Jun 2020 09:33:55 EDT Received: by unicorn.mansr.com (Postfix, from userid 51770) id 6C3D515360; Fri, 26 Jun 2020 14:33:54 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Wolfram Sang Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] i2c: core: check returned size of emulated smbus block read References: <20200613104109.2989-1-mans@mansr.com> <20200626082208.GA4559@kunai> Date: Fri, 26 Jun 2020 14:33:54 +0100 In-Reply-To: <20200626082208.GA4559@kunai> (Wolfram Sang's message of "Fri, 26 Jun 2020 10:22:08 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wolfram Sang writes: > On Sat, Jun 13, 2020 at 11:41:09AM +0100, Mans Rullgard wrote: >> If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of >> them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued > > Out of interest, which driver did you use? I saw it with the mv64xxx (Allwinner) and omap (Beaglebone) drivers. From a quick look, it seems like quite a few others have the same problem. >> on some random device to return an arbitrary value in the first >> byte (and nothing else). When this happens, i2c_smbus_xfer_emulated() >> will happily write past the end of the supplied data buffer, thus >> causing Bad Things to happen. To prevent this, check the size >> before copying the data block and return an error if it is too large. > > Good catch, we were relying on the drivers too much here. I think the > same fix is needed for the non-emulated case as well. Will have a look. > >> + if (msg[1].buf[0] > I2C_SMBUS_BLOCK_MAX) { >> + dev_err(&adapter->dev, >> + "Invalid block size returned: %d\n", >> + msg[1].buf[0]); >> + status = -EINVAL; > > I changed this to -EPROTO as described in > Documentation/i2c/fault-codes.rst. > > Applied to for-current, thanks! > -- M?ns Rullg?rd