From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A4F9F18FDBE; Thu, 25 Jun 2026 13:09:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782392956; cv=none; b=ErcD+A+bpMdMK2KPoLiNVK2vfzLn2WR6eiTolDMkPBuVJzFHuvvau9rvD79T6BleepPZZNiTKuhfv72aRlsWFxs5guh09d28lAmrr0qWINmQ+EJrRpclKsioHWXxncQ3BKUu78G1VMsj4flJF4C/vUP6g37dUQwFG1r2Vp1flwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782392956; c=relaxed/simple; bh=qDjIwXtuEtbNvbvyPCUbxuN5reWP62KKtPPDl6n6OK0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=akTIY1xBiaQ71QnwBzrVr6cAI1EEmnw4a75Zd7AbnwN9cxfnToSp20jcmYYf9TQd/1Qhn2Rx6dcS6f+OPBALhDn33cP8L/1lWvgjs+tl6yaMtOrhvtc5MQGndcxeMHriQkC5ICCXdeVqHcDwG7Qyia8ancPRvKLIIVLrpeuW/ck= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=oRhKkGLf; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="oRhKkGLf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBAA11F000E9; Thu, 25 Jun 2026 13:09:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1782392955; bh=ucxwV5DgkLGZ985cmM3SYdiJZuJdNgAjYoB9uh6tRvU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oRhKkGLfnhPzTxM8TWcXiuzLy5uGR4TR3mc0TxJFteqirQewrOgjE0J30c+vq3Pg4 KWaH4LyUX1vo8FGpbAx+BL9h/XJVd4cQELO54jYz7WSOCqOmQ5o0GeTxIWKP9tVhCF CMEtwOtkRVnSdHYipbDhxmyqAbUfTl19PYJFi670= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Xiang Mei , Weiming Shi , Jean Delvare , Wolfram Sang Subject: [PATCH 7.0 13/49] i2c: stub: Reject I2C block transfers with invalid length Date: Thu, 25 Jun 2026 14:03:25 +0100 Message-ID: <20260625125639.370491945@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260625125637.527552689@linuxfoundation.org> References: <20260625125637.527552689@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Weiming Shi commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/i2c-stub.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/i2c/i2c-stub.c +++ b/drivers/i2c/i2c-stub.c @@ -214,6 +214,11 @@ static s32 stub_xfer(struct i2c_adapter * We ignore banks here, because banked chips don't use I2C * block transfers */ + if (data->block[0] == 0 || + data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret = -EINVAL; + break; + } if (data->block[0] > 256 - command) /* Avoid overrun */ data->block[0] = 256 - command; len = data->block[0];