From: Jonathan Cameron <jic23@kernel.org>
To: Guenter Roeck <groeck@google.com>
Cc: Tzung-Bi Shih <tzungbi@kernel.org>,
bleung@chromium.org, groeck@chromium.org, lars@metafoo.de,
chrome-platform@lists.linux.dev, gwendal@chromium.org,
linux-iio@vger.kernel.org, dianders@chromium.org,
swboyd@chromium.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()
Date: Sun, 3 Sep 2023 12:34:17 +0100 [thread overview]
Message-ID: <20230903123417.51d09285@jic23-huawei> (raw)
In-Reply-To: <CABXOdTfSXJdAz83t-Ndu+MMVLr3KoB37HG3e8_82eE-WmSAZgg@mail.gmail.com>
On Tue, 29 Aug 2023 13:50:59 -0700
Guenter Roeck <groeck@google.com> wrote:
> On Mon, Aug 28, 2023 at 8:06 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and
> > calls iio_push_to_buffers_with_timestamp() without making sure the
> > `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits
> > buffer mode right before cros_ec_sensors_push_data() accesses them.
> >
> > An use-after-free on `indio_dev->active_scan_mask` was observed. The
> > call trace:
> > [...]
> > _find_next_bit
> > cros_ec_sensors_push_data
> > cros_ec_sensorhub_event
> > blocking_notifier_call_chain
> > cros_ec_irq_thread
> >
> > It was caused by a race condition: one thread just freed
> > `active_scan_mask` at [1]; while another thread tried to access the
> > memory at [2].
> >
> > Fix it by calling iio_device_claim_buffer_mode() to ensure the
> > `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data().
> >
> > [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffer.c#L1189
> > [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c#L198
> >
> > Cc: stable@vger.kernel.org
> > Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")
> > Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
>
> Reviewed-by: Guenter Roeck <groeck@chromium.org>
Applied to the fixes-togreg branch of iio.git. Note I'll be rebasing that tree on rc1 before
I send a pull request. So this will take a week or two to go upstream.
Thanks,
Jonathan
>
> > ---
> > Changes from v1(https://patchwork.kernel.org/project/linux-iio/patch/20230828094339.1248472-1-tzungbi@kernel.org/):
> > - Use iio_device_{claim|release}_buffer_mode() instead of accessing `mlock`.
> >
> > drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > index b72d39fc2434..6bfe5d6847e7 100644
> > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > @@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev,
> > /*
> > * Ignore samples if the buffer is not set: it is needed if the ODR is
> > * set but the buffer is not enabled yet.
> > + *
> > + * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer
> > + * is not enabled.
> > */
> > - if (!iio_buffer_enabled(indio_dev))
> > + if (iio_device_claim_buffer_mode(indio_dev) < 0)
> > return 0;
> >
> > out = (s16 *)st->samples;
> > @@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev,
> > iio_push_to_buffers_with_timestamp(indio_dev, st->samples,
> > timestamp + delta);
> >
> > + iio_device_release_buffer_mode(indio_dev);
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data);
> > --
> > 2.42.0.rc2.253.gd59a3bf2b4-goog
> >
next prev parent reply other threads:[~2023-09-03 11:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 3:06 [PATCH v2] iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data() Tzung-Bi Shih
2023-08-29 20:47 ` Stephen Boyd
2023-08-29 20:50 ` Guenter Roeck
2023-09-03 11:34 ` Jonathan Cameron [this message]
2023-11-13 3:23 ` patchwork-bot+chrome-platform
2023-11-13 3:42 ` patchwork-bot+chrome-platform
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230903123417.51d09285@jic23-huawei \
--to=jic23@kernel.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dianders@chromium.org \
--cc=groeck@chromium.org \
--cc=groeck@google.com \
--cc=gwendal@chromium.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=swboyd@chromium.org \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.