[PATCH libXi 3/3] If the XGetDeviceDontPropagateList reply has an invalid length, return 0

If we skip over the reply data, return 0 as number of event classes. Follow-up to 6dd6dc51a2935c72774be81e5cc2ba2c30e9feff. Signed-off-by: Peter Hutterer --- src/XGetProp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/XGetProp.c b/src/XGetProp.c index b49328c..8c69

[PATCH libXi 2/3] Change size += to size = in XGetDeviceControl

size += blah is technically correct but it implies that we're looping or otherwise incrementing the size. Which we don't, it's only ever set once. Change this to avoid reviewer confusion. Reported-by: Dave "color-me-confused" Airlie Signed-off-by: Peter Hutterer --- src/XGetDCtl.c | 10 +--

[PATCH libXi 1/3] Fix potential corruption in mask_len handling

First: check for allocation failure on the mask. XI2 requires that the mask is zeroed, so we can't just Data() the mask provided by the client (it will pad) - we need a tmp buffer. Make sure that doesn't fail. Second: req->mask_len is a uint16_t, so check against malicious mask_lens that would cau

Re: [RFC][PATCH] Make GetXIDRange O(1) instead of O(N^2)

I can't give this a full review, but off-hand it seems like a good idea to me! Changing the max hash size should probably be a separate commit with a commit message justifying it. There's some precedent for putting common data structures in shared code in xserver, notably include/list.h. (Althoug

Re: XGetDeviceControl inconsistency

On 05/26/13 04:54 PM, Dave Airlie wrote: So reviewing the libXi security fix made me double take, there was a few lines like if (sizeof(xDeviceAbsCalibState) > nbytes) goto out; size += sizeof(XDeviceAbsCalibState); Now either size is always 0 going in

Re: [PATCH] libXvMC: avoid overflowing by making nameLen and busIDLen addition overflow

On Mon, May 27, 2013 at 09:45:06 +1000, Dave Airlie wrote: > From: Dave Airlie > > Al Viro pointed this out on lwn, and I think this patch should fix it, > but making sure we don't do the addition as 32-bit on 64-bit machines. > How about this instead: diff --git a/src/XvMC.c b/src/XvMC.c inde

Re: [PATCH] libXrender: avoid possible overflow with multiple members

Hi Dave, On Mon, May 27, 2013 at 08:56:34 +1000, Dave Airlie wrote: > From: Dave Airlie > > If all of these limits are pushed to their mask, then / 4 won't stop I assume s/mask/max/ > the malloc from being overflowed. > > Signed-off-by: Dave Airlie > --- > src/Xrender.c | 10 +- >

Please backport d8d3c78b6ebdf63836951d2dbd2d3d621ff26da2 to server-1.14-branch

Without this fix, the X server is unusable on platforms where char defaults to unsigned. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-deve

[RFC][PATCH] Make GetXIDRange O(1) instead of O(N^2)

Hi, I would like feedback about this patch (do not consider it ready to merge!) The GetXIDRange function in dix/resource.c can show incredibly bad performance in some cases; it can degenerate to O(N*2) behavior and make the system completely unusable. (see http://lists.x.org/archives/xorg-devel/2

[PATCH] Fix libXpm build with NO_ZPIPE

When NO_ZPIPE is defined, fcntl.h is not included in WrFFrI.c although OpenWriteFile uses open, O_WRONLY, O_CREAT and O_TRUNC. * src/WrFFrI.c: unconditionally include fcntl.h regardless of NO_ZPIPE being defined or not. --- Note, this fixes the build on MS Windows where FOR_MSW triggers t

[PATCH] dix: Include selection.h directly.

Fixes the implicit declaration of DeleteWindowFromAnySelections during debian's udeb build. Signed-off-by: Maarten Lankhorst --- diff --git a/dix/window.c b/dix/window.c index a5b28a6..6446c92 100644 --- a/dix/window.c +++ b/dix/window.c @@ -120,6 +120,7 @@ Equipment Corporation. #include "pano