Received: by 10.223.185.116 with SMTP id b49csp6357202wrg; Wed, 28 Feb 2018 08:06:41 -0800 (PST) X-Google-Smtp-Source: AH8x2269tMvw1NSBN1iBAagqVuplW4dwUdmLGoW7U7Dad37eaK2xmugdbSg9LkCRiUKUof3e5PhW X-Received: by 10.101.72.136 with SMTP id n8mr14777043pgs.201.1519834001247; Wed, 28 Feb 2018 08:06:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519834001; cv=none; d=google.com; s=arc-20160816; b=vmSXFCbVlawlAGcKOFdEUrWFkP4W1k8OKdFUikIP+mWDSa4rM+0LhSepw5Hq3LH7DM JRmJ9cBy6C/GD1tHadYcB7APJmvfJsMPZt+QTIIhTkvztw5hUVC59WG0C0k196MHr6uC rRoJuDbhJZljUNXHKwLgJEwJx18Y6r3EXLwsukBCN6AHLr07ZtFQYon9m5qNHkjrGABw Z0/tdMnNc7gNeI+aCIKAKUHzZnE5A6wDFrlg1rH37wSI779XDN2TwazmEUNk8AINJkxe zOJLMuQa7alfvWAjjT1YBIMQS1Sdw8WXp9F2DE+4nveD0Rd/XyehNhBKUbd4gRpc2B/y kgwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=XnBzcxXIeP4X/vRMf6e4+jUv84yEJ1ohNRSsyVBIQU0=; b=aX9ThXWVkNfzeo/3VlZq6FVrwX8FauBDXqLMylgTPqOfg45c92YV+lcPNWGPcYLYLM 1vtNc8Xe4eXKVgYM7917/c880S17vGZDJr9IeANkgVLuX/kZV2XbBlvnDmmPaArwLdip SD6CcaeoK4W2wBTwRAtQ4lZ9p/BLa43uZc/USYq/6uXWfnt4xPYn8EVkE+s8eONljtFD c43FYp/HZnkFvRAI/ImXICK+/Ef/8H40xztmZlUr1alZxQJreLu5f47JYo0ruPs2/flS 9s7+RM/a7OY4tzO72qEZqWbzcQ23QNFF5ZAUaJAa4lE3nZVHNwUjda05jlaJvxBMqw+K gRWA== 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 e13si1405741pff.8.2018.02.28.08.06.26; Wed, 28 Feb 2018 08:06:41 -0800 (PST) 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 S934086AbeB1QDu (ORCPT + 99 others); Wed, 28 Feb 2018 11:03:50 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34786 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932290AbeB1QDs (ORCPT ); Wed, 28 Feb 2018 11:03:48 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yo-0006kw-CC; Wed, 28 Feb 2018 15:22:26 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yk-0000HO-7Q; Wed, 28 Feb 2018 15:22:22 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Wolfram Sang" , "Jeremy Compostella" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 217/254] i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jeremy Compostella commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream. On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes data out of the msgbuf1 array boundary. It is possible from a user application to run into that issue by calling the I2C_SMBUS ioctl with data.block[0] greater than I2C_SMBUS_BLOCK_MAX + 1. This patch makes the code compliant with Documentation/i2c/dev-interface by raising an error when the requested size is larger than 32 bytes. Call Trace: [] dump_stack+0x67/0x92 [] panic+0xc5/0x1eb [] ? vprintk_default+0x1f/0x30 [] ? i2cdev_ioctl_smbus+0x303/0x320 [] __stack_chk_fail+0x1b/0x20 [] i2cdev_ioctl_smbus+0x303/0x320 [] i2cdev_ioctl+0x4d/0x1e0 [] do_vfs_ioctl+0x2ba/0x490 [] ? security_file_ioctl+0x43/0x60 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x6a Signed-off-by: Jeremy Compostella Signed-off-by: Wolfram Sang [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings --- drivers/i2c/i2c-core.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -2481,16 +2481,17 @@ static s32 i2c_smbus_xfer_emulated(struc the underlying bus driver */ break; case I2C_SMBUS_I2C_BLOCK_DATA: + if (data->block[0] > I2C_SMBUS_BLOCK_MAX) { + dev_err(&adapter->dev, "Invalid block %s size %d\n", + read_write == I2C_SMBUS_READ ? "read" : "write", + data->block[0]); + return -EINVAL; + } + if (read_write == I2C_SMBUS_READ) { msg[1].len = data->block[0]; } else { msg[0].len = data->block[0] + 1; - if (msg[0].len > I2C_SMBUS_BLOCK_MAX + 1) { - dev_err(&adapter->dev, - "Invalid block write size %d\n", - data->block[0]); - return -EINVAL; - } for (i = 1; i <= data->block[0]; i++) msgbuf0[i] = data->block[i]; }