linux-kernel - Re: [PATCH] media: hantro: fix use after free bug in hantro

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1c1e4e60-3b90-f268-8012-3193e1de4769@xs4all.nl>
Date:   Mon, 13 Mar 2023 14:47:01 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Zheng Hacker <hackerzheng666@...il.com>
Cc:     Zheng Wang <zyytlz.wz@....com>, ezequiel@...guardiasur.com.ar,
        p.zabel@...gutronix.de, mchehab@...nel.org,
        linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org,
        linux-kernel@...r.kernel.org, 1395428693sheep@...il.com,
        alex000young@...il.com
Subject: Re: [PATCH] media: hantro: fix use after free bug in hantro_release
 due to race condition

On 13/03/2023 14:45, Zheng Hacker wrote:
> Hans Verkuil <hverkuil@...all.nl> 于2023年3月13日周一 21:17写道：
>>
>> On 07/03/2023 16:35, Zheng Wang wrote:
>>> In hantro_probe, vpu->watchdog_work is bound with
>>> hantro_watchdog. Then hantro_end_prepare_run may
>>> be called to start the work.
>>>
>>> If we close the file or remove the module which will
>>> call hantro_release and hantro_remove to make cleanup,
>>> there may be a unfinished work. The possible sequence
>>> is as follows, which will cause a typical UAF bug.
>>>
>>> The same thing will happen in hantro_release, and use
>>> ctx after freeing it.
>>>
>>> Fix it by canceling the work before cleanup in hantro_release.
>>>
>>> CPU0                  CPU1
>>>
>>>                     |hantro_watchdog
>>> hantro_remove     |
>>>   v4l2_m2m_release  |
>>>     kfree(m2m_dev); |
>>>                     |
>>>                     | v4l2_m2m_get_curr_priv
>>>                     |   m2m_dev->curr_ctx //use
>>>
>>> Signed-off-by: Zheng Wang <zyytlz.wz@....com>
>>> ---
>>>  drivers/media/platform/verisilicon/hantro_drv.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
>>> index b0aeedae7b65..cf00ccaa7829 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_drv.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
>>> @@ -601,6 +601,7 @@ static int hantro_release(struct file *filp)
>>>        * No need for extra locking because this was the last reference
>>>        * to this file.
>>>        */
>>> +     cancel_delayed_work(&vpu->watchdog_work);
>>>       v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>>>       v4l2_fh_del(&ctx->fh);
>>>       v4l2_fh_exit(&ctx->fh);
>>
>> drivers/media/platform/verisilicon/hantro_drv.c: In function ‘hantro_release’:
>> drivers/media/platform/verisilicon/hantro_drv.c:604:30: error: ‘vpu’ undeclared (first use in this function); did you mean ‘fpu’?
>>   604 |         cancel_delayed_work(&vpu->watchdog_work);
>>       |                              ^~~
>>       |                              fpu
>> drivers/media/platform/verisilicon/hantro_drv.c:604:30: note: each undeclared identifier is reported only once for each function it appears in
>>
>> You clearly didn't compile this patch!
>>
> Sorry for my mistake. I was hurried to report the issue and discuss
> with developer to confirm it . I'll complete it and test it locally.

Was this UAF actually observed, or is it theoretical?

Regards,

	Hans

> 
> Best regards,
> Zheng