linux-kernel - Re: [PATCH v3] iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cbd2f040-9377-4862-ae52-aac35adb1b9d@linaro.org>
Date: Thu, 6 Nov 2025 16:24:07 +0200
From: Eugen Hristev <eugen.hristev@...aro.org>
To: Jonathan Cameron <jic23@...nel.org>, Pei Xiao <xiaopei01@...inos.cn>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] iio: adc: at91-sama5d2_adc: Fix potential
 use-after-free in sama5d2_adc driver



On 11/2/25 13:54, Jonathan Cameron wrote:
> On Wed, 29 Oct 2025 10:40:16 +0800
> Pei Xiao <xiaopei01@...inos.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 but
>> quite a bit later. 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 a bit later         |
>>                                      | iio_push_to_buffers(indio_dev)
>>                                      | //use indio_dev
>>
>> 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")
> This ID doesn't exist in my history  it should be
> 23ec2774f1cc
> 
> I'll fix that up whilst applying.  Ideally I'd like Eugen to take a look
> but I'm fairly confident so I'll queue this up on the fixes-togreg branch
> of iio.git and mark it for stable.
> 
> Thanks,
> 
> Jonathan
> 
> 
> 
>> Signed-off-by: Pei Xiao <xiaopei01@...inos.cn>
>> ---
>> changlog in v3: move cancel_work_sync after iio_device_unregister
>> changlog in v2: use correct Fix id
>> ---
>>  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..aa4ba3f5a506 100644
>> --- a/drivers/iio/adc/at91-sama5d2_adc.c
>> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
>> @@ -2481,6 +2481,7 @@ static void at91_adc_remove(struct platform_device *pdev)
>>  	struct at91_adc_state *st = iio_priv(indio_dev);
>>  
>>  	iio_device_unregister(indio_dev);
>> +	cancel_work_sync(&st->touch_st.workq);

Hi Jonathan,

Can we push to buffers *after* device was unregistered with
iio_device_unregister() ? Is that right ? Both Pei and I considered it's
not.

Eugen



>>  
>>  	at91_adc_dma_disable(st);
>>  
>