Summary: | poor colormap management | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | TSUKAHARA Ken <ken3> | ||||||
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||
Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | critical | ||||||||
Priority: | highest | CC: | alan.coopersmith | ||||||
Version: | unspecified | Keywords: | patch, security | ||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
TSUKAHARA Ken
2006-12-15 10:20:18 UTC
Created attachment 8131 [details]
Attack Code
Created attachment 8132 [details] [review] Workaround Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. Is this actually a security bug? Unless this makes us double-free something very specific I can't see how this is an actual compromise. So do we want to declare this not a security bug and make it public? (Is denial-of-color a recognized form of security flaw?) No objections after over 2 years, so making the bug publicly viewable. Closing; if you want to reopen this, I'd heavily suggest talking about it on the mailing list first. ajax's comments: Nack in its current form at least. These hunks are bogus: > --- a/dix/colormap.c > +++ b/dix/colormap.c > @@ -811,6 +811,7 @@ AllocColor (ColormapPtr pmap, > VisualPtr pVisual; > int npix; > Pixel *ppix; > + int initialPixels = pmap->numPixelsRed[client]; > > pVisual = pmap->pVisual; > (*pmap->pScreen->ResolveColor) (pred, pgreen, pblue, pVisual); > @@ -970,8 +971,15 @@ AllocColor (ColormapPtr pmap, > } > pcr->mid = pmap->mid; > pcr->client = client; > - if (!AddResource(FakeClientID(client), RT_CMAPENTRY, (pointer)pcr)) > - return (BadAlloc); > + if (class == PseudoColor) { > + if (initialPixels == 0) { > + if (!AddResource(FakeClientID(client), RT_CMAPENTRY, (pointer)pcr)) > + return (BadAlloc); > + } > + } else { > + if (!AddResource(FakeClientID(client), RT_CMAPENTRY, (pointer)pcr)) > + return (BadAlloc); > + } > } > return (Success); > } In the second hunk, we're inside a conditional on if ((pmap->numPixelsRed[client] == 1) && /* ... */ And, if we're PseudoColor, we don't increment numPixelsRed[client] between these two hunks. So the if (initialPixels == 0) conditional is really if (0). Which is definitely wrong; if a client allocates a color in a pseudocolor map, that color needs to be GC'd at client death. The rest of it seems to be changing ->refcnt in EntryPtr from "count of how many times this color has been allocated" to "count of how many clients have allocated this color", which I'm pretty sure would need to be reflected in more places than just FindColor. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.