public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Pei Xiao <xiaopei01@kylinos.cn>
Cc: eugen.hristev@linaro.org, alexandre.belloni@bootlin.com,
	lars@metafoo.de, linux-arm-kernel@lists.infradead.org,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	nicolas.ferre@microchip.com
Subject: Re: [PATCH v2] iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver
Date: Mon, 27 Oct 2025 13:49:08 +0000	[thread overview]
Message-ID: <20251027134908.36d63b9f@jic23-huawei> (raw)
In-Reply-To: <268cbf0a5d9b931fcf6c025c53cc698ce78e4689.1760946527.git.xiaopei01@kylinos.cn>

On Mon, 20 Oct 2025 15:49:25 +0800
Pei Xiao <xiaopei01@kylinos.cn> wrote:

> at91_adc_interrupt can call at91_adc_touch_data_handler function
> to start the work by schedule_work(&st->touch_st.workq).
> 
> If we remove the module which will call at91_adc_remove to
> make cleanup, it will free indio_dev through iio_device_unregister
> while the work mentioned above will be used. The sequence of operations
> that may lead to a UAF bug is as follows:
> 
> CPU0                                      CPU1
> 
>                                      | at91_adc_workq_handler
> at91_adc_remove                      |
> iio_device_unregister(indio_dev)     |
> //free indio_dev                     |
>                                      | iio_push_to_buffers(indio_dev)
>                                      | //use indio_dev

Hi,

I'm not completely following your description here.
The free doesn't happen in iio_device_unregister() but quite a bit later.
So either the problem you are seeing is actually devm_ tear down that
will do the free, or it's a more specific action in iio_device_unregister()
though I'm not sure what it might be. Possibly a specific buffer mask
getting torn down?  I haven't analysed it closely enough to figure out if
there is a race there but it's the only thing I can immediately spot that
would even be of interest to a work item in a driver via some core interfaces.

Other than working out exact cause for anyone looking at this later, I'm
also not sure you don't leave a potential race where a fresh request comes in
between that cancel_work_sync() and the iio_device_unregister() call as it
is only when iio_device_unregister() is complete that all interfaces are torn
down that could start a fresh capture.

So were the cancel_work_sync() one line later I would have been happy but
from your description I'm not sure that fixes the bug you are seeing!

Jonathan



> 
> Fix it by ensuring that the work is canceled before proceeding with
> the cleanup in at91_adc_remove.
> 
> Fixes: 3ec2774f1cc ("iio: adc: at91-sama5d2_adc: add support for position and pressure channels")
> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
> ---
>  drivers/iio/adc/at91-sama5d2_adc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
> index b4c36e6a7490..1cd6ce61cf17 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -2480,6 +2480,7 @@ static void at91_adc_remove(struct platform_device *pdev)
>  	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>  	struct at91_adc_state *st = iio_priv(indio_dev);
>  
> +	cancel_work_sync(&st->touch_st.workq);
>  	iio_device_unregister(indio_dev);
>  
>  	at91_adc_dma_disable(st);



  reply	other threads:[~2025-10-27 13:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28  6:45 [PATCH] iio: adc: at91-sama5d2_adc: Fix use-after-free in sama5d2_adc driver Pei Xiao
2024-11-28  7:26 ` Eugen Hristev
2025-10-20  7:49   ` [PATCH v2] iio: adc: at91-sama5d2_adc: Fix potential " Pei Xiao
2025-10-27 13:49     ` Jonathan Cameron [this message]
2025-10-20  9:26   ` [PATCH] iio: adc: ti_am335x_adc: Limit step_avg to valid range for gcc complains Pei Xiao

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=20251027134908.36d63b9f@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=eugen.hristev@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=xiaopei01@kylinos.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox