linux-kernel - Re: [PATCH] media: dvb-frontends/cxd2099: report errors

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: <b274b6b1-e2ac-2b68-9fb8-502255ca6982@redhat.com>
Date:   Thu, 3 Sep 2020 07:41:27 -0700
From:   Tom Rix <trix@...hat.com>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     jasmin@....at, o.endriss@....de, rjkm@...zlerbros.de,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: dvb-frontends/cxd2099: report errors


On 9/3/20 7:13 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 22 Jul 2020 06:41:26 -0700
> trix@...hat.com escreveu:
>
>> From: Tom Rix <trix@...hat.com>
>>
>> Clang static analysis reports this error
>>
>> drivers/media/dvb-frontends/cxd2099.c:420:2: warning: Undefined
>>   or garbage value returned to caller
>>         return val;
>>         ^~~~~~~~~~
>>
>> In read_cam_control, the call to read_io can fail.
>> When it fails val is not set.
>>
>> The failure status should be returned to the caller,
>> not the unset val.
>>
>> Similar problem with read_attribute_mem
>>
>> Fixes: 0f0b270f905b ("[media] ngene: CXD2099AR Common Interface driver")
>>
>> Signed-off-by: Tom Rix <trix@...hat.com>
>> ---
>>  drivers/media/dvb-frontends/cxd2099.c | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/dvb-frontends/cxd2099.c b/drivers/media/dvb-frontends/cxd2099.c
>> index f88b5355493e..9dfaf18fc4b4 100644
>> --- a/drivers/media/dvb-frontends/cxd2099.c
>> +++ b/drivers/media/dvb-frontends/cxd2099.c
>> @@ -387,12 +387,15 @@ static int read_attribute_mem(struct dvb_ca_en50221 *ca,
>>  {
>>  	struct cxd *ci = ca->data;
>>  	u8 val;
>> +	int ret;
>>  
>>  	mutex_lock(&ci->lock);
>>  	set_mode(ci, 1);
>> -	read_pccard(ci, address, &val, 1);
>> +	ret = read_pccard(ci, address, &val, 1);
>> +	if (!ret)
>> +		ret = val;
>>  	mutex_unlock(&ci->lock);
>> -	return val;
>> +	return ret;
>>  }
>>  
>>  static int write_attribute_mem(struct dvb_ca_en50221 *ca, int slot,
>> @@ -412,12 +415,15 @@ static int read_cam_control(struct dvb_ca_en50221 *ca,
>>  {
>>  	struct cxd *ci = ca->data;
>>  	unsigned int val;
>> +	int ret;
>>  
>>  	mutex_lock(&ci->lock);
>>  	set_mode(ci, 0);
>> -	read_io(ci, address, &val);
>> +	ret = read_io(ci, address, &val);
>> +	if (!ret)
>> +		ret = val;
>>  	mutex_unlock(&ci->lock);
>> -	return val;
>> +	return ret;
>>  }
>>  
>>  static int write_cam_control(struct dvb_ca_en50221 *ca, int slot,
> Hmm... Had you test this one on a real hardware? It is not
> uncommon to have some DVB devices that would fail reading
> when the firmware is on cold state.
>
> Without testing a patch like that at a real hardware, there's
> no way to know if this is intentional or if the original
> developer forgot to add a check for the error.

No, I do not have hw.  I understand your concerns, it is ok if you want to drop this patch, else i'll beef up the warnings.

Tom

>
> So, at most, it could print some warning message for
> non-zero return codes.
>
>
> Thanks,
> Mauro
>