Re: [PATCH] zl10353 and qt1010: fix stack corruption bug

[Jan Nikitenko <jan.nikitenko@gmail.com>]

Mauro Carvalho Chehab wrote:
> Em Wed, 10 Jun 2009 08:21:20 +0200
> Jan Nikitenko <jan.nikitenko@gmail.com> escreveu:
> 
>> This patch fixes stack corruption bug present in dump_regs function of zl10353 
>> and qt1010 drivers:
>> the buffer buf is one byte smaller than required - there is 4 chars
>> for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
>> and 1 byte for zero ending the string required, i.e. 53 bytes, but
>> only 52 were provided.
>> The one byte missing in stack based buffer buf can cause stack corruption 
>> possibly leading to kernel oops, as discovered originally with af9015 driver.
>>
>> Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
>>
>> ---
>>
>> Antti Palosaari wrote:
>>  > On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
>>  >> Solved with "[PATCH] af9015: fix stack corruption bug".
>>  >
>>  > This error leads to the zl10353.c and there it was copied to qt1010.c
>>  > and af9015.c.
>>  >
>> Antti, thanks for pointing out that the same problem was also in zl10353.c and 
>> qt1010.c. Include your Sign-off-by, please.
>>
>> Best regards,
>> Jan
>>
>>   linux/drivers/media/common/tuners/qt1010.c  |    2 +-
>>   linux/drivers/media/dvb/frontends/zl10353.c |    2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff -r cff06234b725 linux/drivers/media/common/tuners/qt1010.c
>> --- a/linux/drivers/media/common/tuners/qt1010.c	Sun May 31 23:07:01 2009 +0300
>> +++ b/linux/drivers/media/common/tuners/qt1010.c	Wed Jun 10 07:37:51 2009 +0200
>> @@ -65,7 +65,7 @@
>>   /* dump all registers */
>>   static void qt1010_dump_regs(struct qt1010_priv *priv)
>>   {
>> -	char buf[52], buf2[4];
>> +	char buf[4+3*16+1], buf2[4];
> 
> CodingStyle is incorrect. It should be buf[4 + 3 * 16 + 1].

right.

> 
> 
>>   	u8 reg, val;
>>
>>   	for (reg = 0; ; reg++) {
>> diff -r cff06234b725 linux/drivers/media/dvb/frontends/zl10353.c
>> --- a/linux/drivers/media/dvb/frontends/zl10353.c	Sun May 31 23:07:01 2009 +0300
>> +++ b/linux/drivers/media/dvb/frontends/zl10353.c	Wed Jun 10 07:37:51 2009 +0200
>> @@ -102,7 +102,7 @@
>>   static void zl10353_dump_regs(struct dvb_frontend *fe)
>>   {
>>   	struct zl10353_state *state = fe->demodulator_priv;
>> -	char buf[52], buf2[4];
>> +	char buf[4+3*16+1], buf2[4];
> 
> Same CodingStyle issue here.

agreed.

> 
>>   	int ret;
>>   	u8 reg;
>>
> 
> Without having actually looking at the source code, would it be possible to
> change the logic in order to use something else instead of a magic number for
> buf size - e. g. using sizeof(something) ?

I am not sure if that's possible - the buffer is used for sprintf in a loop to 
store text representation of registers dump, before printk-ing it.

We could put there a comment, suggesting that 4 bytes are required for address 
prefix of form "00: ", then 16 strings of form "00 " (3 bytes each) and one byte 
for zero to terminate the string.

Or we could use sizeof, like this:
    char buf[sizeof("00: ") - 1 + 16 * (sizeof("00 ") - 1) + 1]
or
    char buf[sizeof("00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ")]
but it is not very readable in my opinion either.

Maybe the best way would be to avoid the need for temporal buffer completely by 
directly using printk in a loop, that is only the first printk with KERN_DEBUG, 
followed by sequence of printk with registers dump and final printk with end of 
line (but isn't a printk without KERN_ facility coding style problem as well?).

I am not sure, what approach is the best - I just wanted to fix a bug, which did 
not allow to use my af9015 based tuner on mips platform. After that, Antti 
pointed out, that the same code with the same bug is also in other two sources, 
so I send the same fix for them as well...

Best regards,
Jan