From patchwork Sun Sep 20 11:27:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Cameron X-Patchwork-Id: 11787465 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C42446CB for ; Sun, 20 Sep 2020 11:28:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AE43F222BB for ; Sun, 20 Sep 2020 11:28:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600601305; bh=eCd5xjxSs8SS2HHXacJLuCqKsSdDpasJjlPPksFyf+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=wRbHZsIvAXvJu6v6W2GG4Wwx51B8NbTzxoCqxeG4XMK29gVvAlMh6qPE4pHzaidXv jpERIFKkshNJnPcOKrIxA/Ujp8MxG8/VQfCxsZmpI+zBBfWMM37QSDZ6xh3u3rOE5c qOiY9FXeVZ8rEYqSar2mMf84MJUreC8qiYueS9m8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726273AbgITL2Z (ORCPT ); Sun, 20 Sep 2020 07:28:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:39416 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726250AbgITL2Z (ORCPT ); Sun, 20 Sep 2020 07:28:25 -0400 Received: from localhost.localdomain (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 914F721BE5; Sun, 20 Sep 2020 11:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600601304; bh=eCd5xjxSs8SS2HHXacJLuCqKsSdDpasJjlPPksFyf+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qS1zgYD4h445cKNxAP38gjI8joo3INbwFGSM1hCmRFzoEyOswMLXg9x6qi+bGg0UJ dZmuH6xfQP0uq2Ks7xF9KuJ4SBTBVdzKAOuuc4FrKTig+g7cqEukPckxiehuRkmNpn pMzvziCMyEK0McVUwrAmLdzMNerbA+g3CCVKFjWk= From: Jonathan Cameron To: linux-iio@vger.kernel.org Cc: Andy Shevchenko , Jonathan Cameron , Mikko Koivunen Subject: [PATCH v4 1/8] iio:light:rpr0521: Fix timestamp alignment and prevent data leak. Date: Sun, 20 Sep 2020 12:27:35 +0100 Message-Id: <20200920112742.170751-2-jic23@kernel.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200920112742.170751-1-jic23@kernel.org> References: <20200920112742.170751-1-jic23@kernel.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org From: Jonathan Cameron One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer") Cc: Mikko Koivunen Signed-off-by: Jonathan Cameron --- v4: Fixed typo. Also added to patch description Mikko's information drivers/iio/light/rpr0521.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/iio/light/rpr0521.c b/drivers/iio/light/rpr0521.c index aa2972b04833..31224a33bade 100644 --- a/drivers/iio/light/rpr0521.c +++ b/drivers/iio/light/rpr0521.c @@ -194,6 +194,17 @@ struct rpr0521_data { bool pxs_need_dis; struct regmap *regmap; + + /* + * Ensure correct naturally aligned timestamp. + * Note that the read will put garbage data into + * the padding but this should not be a problem + */ + struct { + __le16 channels[3]; + u8 garbage; + s64 ts __aligned(8); + } scan; }; static IIO_CONST_ATTR(in_intensity_scale_available, RPR0521_ALS_SCALE_AVAIL); @@ -449,8 +460,6 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p) struct rpr0521_data *data = iio_priv(indio_dev); int err; - u8 buffer[16]; /* 3 16-bit channels + padding + ts */ - /* Use irq timestamp when reasonable. */ if (iio_trigger_using_own(indio_dev) && data->irq_timestamp) { pf->timestamp = data->irq_timestamp; @@ -461,11 +470,11 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p) pf->timestamp = iio_get_time_ns(indio_dev); err = regmap_bulk_read(data->regmap, RPR0521_REG_PXS_DATA, - &buffer, + data->scan.channels, (3 * 2) + 1); /* 3 * 16-bit + (discarded) int clear reg. */ if (!err) iio_push_to_buffers_with_timestamp(indio_dev, - buffer, pf->timestamp); + &data->scan, pf->timestamp); else dev_err(&data->client->dev, "Trigger consumer can't read from sensor.\n");