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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9c96d50-a4d1-29bf-3bb0-68c4f7cd4c10@tsinghua.edu.cn>
Date:   Sun, 30 Aug 2020 15:24:24 +0800
From:   Jia-Ju Bai <baijiaju@...nghua.edu.cn>
To:     Pavel Machek <pavel@....cz>, Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Sean Young <sean@...s.org>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        linux-media@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix
 possible buffer overflow caused by bad DMA value in debiirq()



On 2020/8/29 20:10, Pavel Machek wrote:
> Hi!
>
>> The value av7110->debi_virt is stored in DMA memory, and it is assigned
>> to data, and thus data[0] can be modified at any time by malicious
>> hardware. In this case, "if (data[0] < 2)" can be passed, but then
>> data[0] can be changed into a large number, which may cause buffer
>> overflow when the code "av7110->ci_slot[data[0]]" is used.
>>
>> To fix this possible bug, data[0] is assigned to a local variable, which
>> replaces the use of data[0].
> I'm pretty sure hardware capable of manipulating memory can work
> around any such checks, but...
>
>> +++ b/drivers/media/pci/ttpci/av7110.c
>> @@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
>>   	case DATA_CI_GET:
>>   	{
>>   		u8 *data = av7110->debi_virt;
>> +		u8 data_0 = data[0];
>>   
>> -		if ((data[0] < 2) && data[2] == 0xff) {
>> +		if (data_0 < 2 && data[2] == 0xff) {
>>   			int flags = 0;
>>   			if (data[5] > 0)
>>   				flags |= CA_CI_MODULE_PRESENT;
>>   			if (data[5] > 5)
>>   				flags |= CA_CI_MODULE_READY;
>> -			av7110->ci_slot[data[0]].flags = flags;
>> +			av7110->ci_slot[data_0].flags = flags;
> This does not even do what it says. Compiler is still free to access
> data[0] multiple times. It needs READ_ONCE() to be effective.
>
>

Thanks for this advice, I will submit a v2 patch soon.


Best wishes,
Jia-Ju Bai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ