linux-kernel - Re: [PATCH 1/2] media: venus: fix OOB read issue due to double read

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: <13259345-02b0-47ff-94a8-530a17c50b97@quicinc.com>
Date: Fri, 17 Jan 2025 14:09:20 +0530
From: Vedang Nagar <quic_vnagar@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Stanimir Varbanov
	<stanimir.k.varbanov@...il.com>,
        Vikash Garodia <quic_vgarodia@...cinc.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
CC: <linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] media: venus: fix OOB read issue due to double read

Hi Bryan,

On 1/6/2025 5:28 AM, Bryan O'Donoghue wrote:
> On 04/01/2025 05:41, Vedang Nagar wrote:
>> During message queue read, the address is being read twice
>> from the shared memory. The first read is validated against
>> the size of the packet, however the second read is not
>> being validated.
> 
> A brief scan of this code doesn't really show the base case you assert here.
> 
> Could you be a bit more explicit.
> 
>  Therefore, it's possible for firmware to
>> modify the value to a bigger invalid value which can lead
>> to OOB read access issue while reading the packet.
>> Added fix to reupdate the size of the packet which was
>> read for the first time.
>>
>> Signed-off-by: Vedang Nagar <quic_vnagar@...cinc.com>
>> ---
>>   drivers/media/platform/qcom/venus/hfi_venus.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
>> index f9437b6412b91c2483670a2b11f4fd43f3206404..64cc9e916f53e5a9c82b1ff25c4475d622ebc321 100644
>> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
>> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
>> @@ -298,6 +298,7 @@ static int venus_read_queue(struct venus_hfi_device *hdev,
>>               memcpy(pkt, rd_ptr, len);
>>               memcpy(pkt + len, queue->qmem.kva, new_rd_idx << 2);
>>           }
>> +        memcpy(pkt, (u32 *)(queue->qmem.kva + (rd_idx << 2)), sizeof(u32));
> 
> I'm not entirely following your reasoning here.
> 
> Here's how the code looks after your change:
> 
> if (new_rd_idx < qsize) {
>     memcpy(pkt, rd_ptr, dwords << 2);
> } else {
>     size_t len;
>     
>     new_rd_idx -= qsize;
>     len = (dwords - new_rd_idx) << 2;
>     memcpy(pkt, rd_ptr, len);
>     memcpy(pkt + len, queue->qmem.kva, new_rd_idx << 2);
> }
> 
> memcpy(pkt, (u32 *)(queue->qmem.kva + (rd_idx << 2)), sizeof(u32));
> 
> Which of the above memcpy() operations is subject to a pointer that firmware can influence exactly ?
Below is the first read where dwords is being validated properly with the checks.
dwords = *rd_ptr >> 2;

Whereas the same address is being read for the second time:
memcpy(pkt, rd_ptr, dwords << 2);

For the second read the value is not validated which may get updated from the firmware
leading to incorrect memcpy into the packet and may lead to OOB read access while accessing
the packet.

To avoid the issue, planning to repopulate the pkt with the first read like below:
 *(u32 *)pkt = dwords << 2;
Pls ignore the original solution which seems to be not correct.
Pls let me know if it looks good, will fix it in next version.

Regards,
Vedang Nagar
> 
> Is this a real problem you've seen if so please add a backtrace to this commit log.
> 
>>       } else {
>>           /* bad packet received, dropping */
>>           new_rd_idx = qhdr->write_idx;
>>
> 
> If this is a fix it requires a Fixes: tag.
> 
> Please add.
> 
> Still finding the reasoning you are outlining here not obvious.
> 
> ---
> bod