All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [bug report] out of bounds read parsing vmode commandline option
Date: Tue, 17 Oct 2017 13:37:20 +0000	[thread overview]
Message-ID: <5014119.cNFvECyesu@amdc3058> (raw)
In-Reply-To: <CAMuHMdUNvtDunWK-4oRFMqTVz_QKzXW_Fosg883jd7Wu7mp3_A@mail.gmail.com>


Hi,

On Wednesday, October 04, 2017 06:42:37 PM Geert Uytterhoeven wrote:
> Hi Dan,
> 
> On Wed, Oct 4, 2017 at 2:50 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > This bug predates git but it looks like it might be simple to fix if the
> > right person looked at the code.
> >
> >         drivers/video/fbdev/controlfb.c:560 control_setup()
> >         error: buffer overflow 'control_mac_modes' 20 <= 21
> >
> > drivers/video/fbdev/controlfb.c
> >    549  static void __init control_setup(char *options)
> >    550  {
> >    551          char *this_opt;
> >    552
> >    553          if (!options || !*options)
> >    554                  return;
> >    555
> >    556          while ((this_opt = strsep(&options, ",")) != NULL) {
> >    557                  if (!strncmp(this_opt, "vmode:", 6)) {
> >    558                          int vmode = simple_strtoul(this_opt+6, NULL, 0);
> >                                     ^^^^^
> > We get vmode from the command line.
> >
> >    559                          if (vmode > 0 && vmode <= VMODE_MAX &&
> >                                                           ^^^^^^^^^
> > We check that it's <= 22.
> >
> >    560                              control_mac_modes[vmode - 1].m[1] >= 0)
> >                                     ^^^^^^^^^^^^^^^^^
> > But the problem is that control_mac_modes[] only has 20 elements so the
> > highest valid index is 19.  vmode - 1 can be up to 21.
> 
> Nice catch!
> 
> The bug was introduced in v2.4.5.6, when 2 new modes were added to
> macmodes.h, but control_mac_modes[] wasn't updated:
> 
> https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id)f279c764808560eaceb88fef36cbc35c529aad
> 
> A simple fix is to check against ARRAY_SIZE(control_mac_modes) instead.
> 
> A better fix is to add the missing entries to control_mac_modes[], cfr. the
> (gmail-whitespace-damaged) patch below:
> 
> --- a/drivers/video/fbdev/controlfb.h
> +++ b/drivers/video/fbdev/controlfb.h
> @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_modes[] = {
>         {{ 1, 2}},      /* 1152x870, 75Hz */
>         {{ 0, 1}},      /* 1280x960, 75Hz */
>         {{ 0, 1}},      /* 1280x1024, 75Hz */
> +       {{ 1, 2}},      /* 1152x768, 60Hz */
> +       {{ 0, 1}},      /* 1600x1024, 60Hz */
>  };
> 
> (this array lists the maximum color mode (8, 16, or 32 bpp) for each
>  video mode given RAM restrictions (2 or 4 MiB)).
> 
> The 1152x768 mode is probably OK. Given the 1600x1024 mode has a lower
> dotclock (112 MHz) than the supported 1280x960 mode, it's probably OK, too.

Looks fine to me, could you please submit it as a normal patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


WARNING: multiple messages have this Message-ID (diff)
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [bug report] out of bounds read parsing vmode commandline option
Date: Tue, 17 Oct 2017 15:37:20 +0200	[thread overview]
Message-ID: <5014119.cNFvECyesu@amdc3058> (raw)
In-Reply-To: <CAMuHMdUNvtDunWK-4oRFMqTVz_QKzXW_Fosg883jd7Wu7mp3_A@mail.gmail.com>


Hi,

On Wednesday, October 04, 2017 06:42:37 PM Geert Uytterhoeven wrote:
> Hi Dan,
> 
> On Wed, Oct 4, 2017 at 2:50 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > This bug predates git but it looks like it might be simple to fix if the
> > right person looked at the code.
> >
> >         drivers/video/fbdev/controlfb.c:560 control_setup()
> >         error: buffer overflow 'control_mac_modes' 20 <= 21
> >
> > drivers/video/fbdev/controlfb.c
> >    549  static void __init control_setup(char *options)
> >    550  {
> >    551          char *this_opt;
> >    552
> >    553          if (!options || !*options)
> >    554                  return;
> >    555
> >    556          while ((this_opt = strsep(&options, ",")) != NULL) {
> >    557                  if (!strncmp(this_opt, "vmode:", 6)) {
> >    558                          int vmode = simple_strtoul(this_opt+6, NULL, 0);
> >                                     ^^^^^
> > We get vmode from the command line.
> >
> >    559                          if (vmode > 0 && vmode <= VMODE_MAX &&
> >                                                           ^^^^^^^^^
> > We check that it's <= 22.
> >
> >    560                              control_mac_modes[vmode - 1].m[1] >= 0)
> >                                     ^^^^^^^^^^^^^^^^^
> > But the problem is that control_mac_modes[] only has 20 elements so the
> > highest valid index is 19.  vmode - 1 can be up to 21.
> 
> Nice catch!
> 
> The bug was introduced in v2.4.5.6, when 2 new modes were added to
> macmodes.h, but control_mac_modes[] wasn't updated:
> 
> https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id=29f279c764808560eaceb88fef36cbc35c529aad
> 
> A simple fix is to check against ARRAY_SIZE(control_mac_modes) instead.
> 
> A better fix is to add the missing entries to control_mac_modes[], cfr. the
> (gmail-whitespace-damaged) patch below:
> 
> --- a/drivers/video/fbdev/controlfb.h
> +++ b/drivers/video/fbdev/controlfb.h
> @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_modes[] = {
>         {{ 1, 2}},      /* 1152x870, 75Hz */
>         {{ 0, 1}},      /* 1280x960, 75Hz */
>         {{ 0, 1}},      /* 1280x1024, 75Hz */
> +       {{ 1, 2}},      /* 1152x768, 60Hz */
> +       {{ 0, 1}},      /* 1600x1024, 60Hz */
>  };
> 
> (this array lists the maximum color mode (8, 16, or 32 bpp) for each
>  video mode given RAM restrictions (2 or 4 MiB)).
> 
> The 1152x768 mode is probably OK. Given the 1600x1024 mode has a lower
> dotclock (112 MHz) than the supported 1280x960 mode, it's probably OK, too.

Looks fine to me, could you please submit it as a normal patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

  reply	other threads:[~2017-10-17 13:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 12:50 [bug report] out of bounds read parsing vmode commandline option Dan Carpenter
2017-10-04 16:42 ` Geert Uytterhoeven
2017-10-04 16:42   ` Geert Uytterhoeven
2017-10-17 13:37   ` Bartlomiej Zolnierkiewicz [this message]
2017-10-17 13:37     ` Bartlomiej Zolnierkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5014119.cNFvECyesu@amdc3058 \
    --to=b.zolnierkie@samsung.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan.carpenter@oracle.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.