[PATCH] tty/metag_da: initialize number_written to zero

[PATCH] tty/metag_da: initialize number_written to zero

[Colin King]

From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>

number_written is not initialized, so it can be any value. In the
case where dport->xmit_cnt is zero, number_written is not set
and subsequent accesses to it will be reading a garbage value.
Fix this by initializing it to zero for the case when
dport->xmit_count is zero.

Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
 drivers/tty/metag_da.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/metag_da.c b/drivers/tty/metag_da.c
index 9325262..3da89c1 100644
--- a/drivers/tty/metag_da.c
+++ b/drivers/tty/metag_da.c
@@ -230,7 +230,7 @@ static int put_channel_data(unsigned int chan)
 {
 	struct dashtty_port *dport;
 	struct tty_struct *tty;
-	int number_written;
+	int number_written = 0;
 	unsigned int count = 0;
 
 	dport = &dashtty_ports[chan];
-- 
2.7.0.rc3

Re: [PATCH] tty/metag_da: initialize number_written to zero

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

Hi Colin,

On Tue, Jan 26, 2016 at 11:37:25PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> 
> number_written is not initialized, so it can be any value. In the
> case where dport->xmit_cnt is zero, number_written is not set
> and subsequent accesses to it will be reading a garbage value.

the only subsequent accesses when dport->xmit_cnt == 0 are:

	/* if we've made more data available, wake up tty */
	if (count && number_written) {

and:

	/* did the write fail? */
	return count && !number_written;

but dport->xmit_cnt == 0 implies count == 0, so number_written shouldn't
be used, and both will evaluate to false regardless of the uninitialised
value, so it looks fine as it is to me.

Is this tripping up some static analysis tool or something?

Thanks
James

> Fix this by initializing it to zero for the case when
> dport->xmit_count is zero.
> 
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
>  drivers/tty/metag_da.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/metag_da.c b/drivers/tty/metag_da.c
> index 9325262..3da89c1 100644
> --- a/drivers/tty/metag_da.c
> +++ b/drivers/tty/metag_da.c
> @@ -230,7 +230,7 @@ static int put_channel_data(unsigned int chan)
>  {
>  	struct dashtty_port *dport;
>  	struct tty_struct *tty;
> -	int number_written;
> +	int number_written = 0;
>  	unsigned int count = 0;
>  
>  	dport = &dashtty_ports[chan];
> -- 
> 2.7.0.rc3
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] tty/metag_da: initialize number_written to zero

[Colin Ian King]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/01/16 11:42, James Hogan wrote:
> Hi Colin,
> 
> On Tue, Jan 26, 2016 at 11:37:25PM +0000, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> number_written is not initialized, so it can be any value. In the
>> case where dport->xmit_cnt is zero, number_written is not set
>> and subsequent accesses to it will be reading a garbage value.
> 
> the only subsequent accesses when dport->xmit_cnt == 0 are:
> 
> 	/* if we've made more data available, wake up tty */
> 	if (count && number_written) {
> 
> and:
> 
> 	/* did the write fail? */
> 	return count && !number_written;
> 
> but dport->xmit_cnt == 0 implies count == 0, so number_written shouldn
't
> be used, and both will evaluate to false regardless of the uninitialis
ed
> value, so it looks fine as it is to me.
> 
> Is this tripping up some static analysis tool or something?

It was found using cppcheck, namely:

[drivers/tty/metag_da.c:269]: (error) Uninitialized variable: number_wri
tten


> 
> Thanks
> James
> 
>> Fix this by initializing it to zero for the case when
>> dport->xmit_count is zero.
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>>  drivers/tty/metag_da.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/metag_da.c b/drivers/tty/metag_da.c
>> index 9325262..3da89c1 100644
>> --- a/drivers/tty/metag_da.c
>> +++ b/drivers/tty/metag_da.c
>> @@ -230,7 +230,7 @@ static int put_channel_data(unsigned int chan)
>>  {
>>  	struct dashtty_port *dport;
>>  	struct tty_struct *tty;
>> -	int number_written;
>> +	int number_written = 0;
>>  	unsigned int count = 0;
>>  
>>  	dport = &dashtty_ports[chan];
>> -- 
>> 2.7.0.rc3
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWqmJvAAoJEGjCh9/GqAImiFMP/R9IVGMLUlhGVrk+nTxg5ojU
ZAlaVWhClt08IGHJULMfSvXXwDe2k7Y9AybUD0DXB1eZvcNX8Grbs9knmQygyl+5
YETHTpYRbDutcH9Ru0wNAAclctMM+iGs0SRCfSsNvPA4OqpQVzZEsiu6QoyAxeCW
xsNkbO0NA15+A+af0jz/WZYAkibQ7S3ijco+O9ttR99aaRM8eMrZJHDdTzozAq60
ZnnQ4VMm287l0Y8Bh94T1E0+3WuonQeCLAM+Wxc43c4vH/Q2lLhxV4TvsmXJTFoQ
WZghBLtkf9Y792wx3uDzLQGBBP4XSSwTtchrhIv/q2mgeyCqFYONvM+Vk8uXTtYp
msRbdR45FB1blG8Asw5gqbMfiqYc0TpHXBmV1KeActYcBOYD9p7kE+pyFism9tK5
7sFb1ud3HnCCjJ31tCKq8Sqdy5UjsUtL46Avn1NBoQqxqCMLMWoEd/kbvMm8xJez
50s6cTIwpB6HKFva3FogUOgZN6fFn4vIegkn9zLtUab8G8ny665M9FyFIhmaS88C
PLjDOnyNzMs1nIReR0Eiw50V9a3ObPnN5zwZ45YgbGeHn9hYMBPWZb3swzovx6JP
d5t1zYZKBYVuIAmBKBM6LusfkDGTeD4yRNWtASmryD85AGNYsW09GgV+7NXE+tUf
xSHwQwslznAKKITlP/MZ
=sini
-----END PGP SIGNATURE-----

Re: [PATCH] tty/metag_da: initialize number_written to zero

[Greg Kroah-Hartman]

On Thu, Jan 28, 2016 at 06:48:17PM +0000, Colin Ian King wrote:
> On 27/01/16 11:42, James Hogan wrote:
> > Hi Colin,
> > 
> > On Tue, Jan 26, 2016 at 11:37:25PM +0000, Colin King wrote:
> >> From: Colin Ian King <colin.king@canonical.com>
> >>
> >> number_written is not initialized, so it can be any value. In the
> >> case where dport->xmit_cnt is zero, number_written is not set
> >> and subsequent accesses to it will be reading a garbage value.
> > 
> > the only subsequent accesses when dport->xmit_cnt == 0 are:
> > 
> > 	/* if we've made more data available, wake up tty */
> > 	if (count && number_written) {
> > 
> > and:
> > 
> > 	/* did the write fail? */
> > 	return count && !number_written;
> > 
> > but dport->xmit_cnt == 0 implies count == 0, so number_written shouldn
> 't
> > be used, and both will evaluate to false regardless of the uninitialis
> ed
> > value, so it looks fine as it is to me.
> > 
> > Is this tripping up some static analysis tool or something?
> 
> It was found using cppcheck, namely:
> 
> [drivers/tty/metag_da.c:269]: (error) Uninitialized variable: number_wri
> tten

Please fix the broken tool, don't paper over it by doing unnecessary
work in the kernel.

thanks,

greg k-h

Re: [PATCH] tty/metag_da: initialize number_written to zero

[Colin Ian King]

On 07/02/16 07:41, Greg Kroah-Hartman wrote:
> On Thu, Jan 28, 2016 at 06:48:17PM +0000, Colin Ian King wrote:
>> On 27/01/16 11:42, James Hogan wrote:
>>> Hi Colin,
>>>
>>> On Tue, Jan 26, 2016 at 11:37:25PM +0000, Colin King wrote:
>>>> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>>>>
>>>> number_written is not initialized, so it can be any value. In the
>>>> case where dport->xmit_cnt is zero, number_written is not set
>>>> and subsequent accesses to it will be reading a garbage value.
>>>
>>> the only subsequent accesses when dport->xmit_cnt == 0 are:
>>>
>>> 	/* if we've made more data available, wake up tty */
>>> 	if (count && number_written) {
>>>
>>> and:
>>>
>>> 	/* did the write fail? */
>>> 	return count && !number_written;
>>>
>>> but dport->xmit_cnt == 0 implies count == 0, so number_written shouldn
>> 't
>>> be used, and both will evaluate to false regardless of the uninitialis
>> ed
>>> value, so it looks fine as it is to me.
>>>
>>> Is this tripping up some static analysis tool or something?
>>
>> It was found using cppcheck, namely:
>>
>> [drivers/tty/metag_da.c:269]: (error) Uninitialized variable: number_wri
>> tten
> 
> Please fix the broken tool, don't paper over it by doing unnecessary
> work in the kernel.
> 
> thanks,
> 
> greg k-h
> 
Sorry Greg, this was my first thinko out of 80 or so fixes I've found
with static analysis. I'll try harder next time not to make a mistake.

Colin