From: "Ville Syrjälä" <syrjala@sci.fi>
To: Roel Kluin <roel.kluin@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: fbcmap: non working tests on unsigned cmap->start
Date: Sun, 26 Apr 2009 16:15:05 +0300 [thread overview]
Message-ID: <20090426131505.GG7134@sci.fi> (raw)
In-Reply-To: <49F4519F.4090003@gmail.com>
On Sun, Apr 26, 2009 at 02:20:47PM +0200, Roel Kluin wrote:
> cmap->start is unsigned, A negative start could result in incorrect
> colors. `start' is used as the starting index for the hardware palette,
> 'start+len-1' is the last index.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> >>> vi include/linux/fb.h +478
> >>>
> >>> Note that struct fb_cmap_user cmap->start in fb_set_user_cmap() is unsigned.
> >>> Should there maybe be a test:
> >>>
> >>> if (cmap->start > MAX || ...)
> >>>
> >>> (and what should MAX be then?)
> >>>
>
> > On Thu, Apr 23, 2009 at 01:41:10PM -0700, Andrew Morton wrote:
> >> argh.
> >>
> >> - Perhaps userspace can kill the kernel by sending a "negative"
> >> `start'. Removing the test will make it even less likely that we'll
> >> fix this bug.
> >
> > Shouldn't happen. 'start' is used as the starting index for the hardware
> > palette, 'start+len-1' is the last index. All drivers should already check
> > the passed values since the maximum index depends on the display mode.
> > And I suppose the worst thing that could happen if the driver fails to
> > check the values would be incorrect colors.
>
> Thanks for your explanation, I think this should fix it?
>
> diff --git a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c
> index f53b9f1..ea62d87 100644
> --- a/drivers/video/fbcmap.c
> +++ b/drivers/video/fbcmap.c
> @@ -266,7 +266,7 @@ int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
> rc = -ENODEV;
> goto out;
> }
> - if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
> + if (cmap->start >= cmap->len || (!info->fbops->fb_setcolreg &&
> !info->fbops->fb_setcmap)) {
> rc = -EINVAL;
> goto out1;
That's not correct. There's nothing wrong with having 'start' >= 'len'.
You would rather need something like
'if (start+len > 1 << max(red.len, green.len, blue.len, transp.len))'
and a check to make sure that start+len doesn't overflow.
Oh and I guess it should also check that the visual is pseudocolor or
directcolor.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <syrjala@sci.fi>
To: Roel Kluin <roel.kluin@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [Linux-fbdev-devel] fbcmap: non working tests on unsigned cmap->start
Date: Sun, 26 Apr 2009 16:15:05 +0300 [thread overview]
Message-ID: <20090426131505.GG7134@sci.fi> (raw)
In-Reply-To: <49F4519F.4090003@gmail.com>
On Sun, Apr 26, 2009 at 02:20:47PM +0200, Roel Kluin wrote:
> cmap->start is unsigned, A negative start could result in incorrect
> colors. `start' is used as the starting index for the hardware palette,
> 'start+len-1' is the last index.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> >>> vi include/linux/fb.h +478
> >>>
> >>> Note that struct fb_cmap_user cmap->start in fb_set_user_cmap() is unsigned.
> >>> Should there maybe be a test:
> >>>
> >>> if (cmap->start > MAX || ...)
> >>>
> >>> (and what should MAX be then?)
> >>>
>
> > On Thu, Apr 23, 2009 at 01:41:10PM -0700, Andrew Morton wrote:
> >> argh.
> >>
> >> - Perhaps userspace can kill the kernel by sending a "negative"
> >> `start'. Removing the test will make it even less likely that we'll
> >> fix this bug.
> >
> > Shouldn't happen. 'start' is used as the starting index for the hardware
> > palette, 'start+len-1' is the last index. All drivers should already check
> > the passed values since the maximum index depends on the display mode.
> > And I suppose the worst thing that could happen if the driver fails to
> > check the values would be incorrect colors.
>
> Thanks for your explanation, I think this should fix it?
>
> diff --git a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c
> index f53b9f1..ea62d87 100644
> --- a/drivers/video/fbcmap.c
> +++ b/drivers/video/fbcmap.c
> @@ -266,7 +266,7 @@ int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
> rc = -ENODEV;
> goto out;
> }
> - if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
> + if (cmap->start >= cmap->len || (!info->fbops->fb_setcolreg &&
> !info->fbops->fb_setcmap)) {
> rc = -EINVAL;
> goto out1;
That's not correct. There's nothing wrong with having 'start' >= 'len'.
You would rather need something like
'if (start+len > 1 << max(red.len, green.len, blue.len, transp.len))'
and a check to make sure that start+len doesn't overflow.
Oh and I guess it should also check that the visual is pseudocolor or
directcolor.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
next prev parent reply other threads:[~2009-04-26 13:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-21 14:26 fbcmap: non working tests on unsigned cmap->start Roel Kluin
2009-04-23 20:41 ` Andrew Morton
2009-04-23 21:47 ` [Linux-fbdev-devel] " Ville Syrjälä
2009-04-23 21:56 ` Andrew Morton
2009-04-26 12:20 ` Roel Kluin
2009-04-26 12:20 ` [Linux-fbdev-devel] " Roel Kluin
2009-04-26 13:15 ` Ville Syrjälä [this message]
2009-04-26 13:15 ` Ville Syrjälä
2009-04-27 11:58 ` Roel Kluin
2009-04-27 11:58 ` [Linux-fbdev-devel] " Roel Kluin
2009-04-27 12:21 ` Geert Uytterhoeven
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=20090426131505.GG7134@sci.fi \
--to=syrjala@sci.fi \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=roel.kluin@gmail.com \
/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.