Em Wed, 10 Jun 2009 08:21:20 +0200
Jan Nikitenko <jan.nikite...@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.nikite...@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].
> 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.
> 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) ?
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
