RegionValidate() copies *badreg into ri[0].reg, so ri[0].reg.data aliases badreg->data. A later
RECTALLOC_BAIL() can realloc() that block and move it, updating ri[0].reg.data but not badreg->data. On
the bail path, freeing ri[0].reg.data and then calling RegionBreak(badreg) frees badreg->data a second
time, which by then is a stale pointer into memory already freed or reallocated to something else.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2281>
(cherry picked from commit 4ef1b4cd26)
(cherry picked from commit bb02769445b1a516f33b4855977cc227f0542cb7)
(cherry picked from commit bc0760d9514fe5f2d9e4f5287ab0318d45c32736)
(cherry picked from commit e84a8065c4)
SwapScrollInfo converted the other multi-byte ScrollClass fields but left flags in server byte order. Swap it as well and decode the field in the swapped-client protocol test so nonzero flags exercise the wire representation.
Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2291>
(cherry picked from commit 8033c4d93e)
(cherry picked from commit 2d1d0b67dc2119507f52e3dae96827b8946d0eca)
(cherry picked from commit db6f28acaa7c7d2a049a92396e1bc35b6f759d8a)
(cherry picked from commit 9f1a06d0b5)
When every key in a keymap has zero groups, ctrls->num_groups is 0 and each out-of-range action here misbehaves.
XkbWrapIntoRange divides by zero, which is the reported crash. XkbClampIntoRange is worse: it computes -1,
returns it through this function's unsigned type, and the callers truncate it into XkbStateRec's unsigned char
group fields as 255, after which XkbComputeCompatState() reads map->groups[255] out of a four element array and
reports what it finds to clients in the compat state of every core event. The negative-group case adds zero
forever, wedging the server thread, in one path while it holds input_lock. XkbComputeDerivedState() treats group
0 as out of range once num_groups is 0, so all of this is reachable from an ordinary key event.
XQuartz gets there because it asks for model "empty", whose keycodes file declares no key names, so a keymap
compiled at a client's request has no key definitions at all.
Guard the arithmetic itself and not just the places that compute num_groups: groups_wrap selects between these
actions and is client settable, and this is exported for DDXes that supply their own controls.
Fixes: https://github.com/XQuartz/XQuartz/issues/422
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2278>
Clamp the count once per key and use it everywhere the key or the keymap is indexed with it, while still reading
every symbol the file claimed so that the stream stays in step and the symbol array is not left short.
At the other end, a symbols section in which no key defines any group leaves the count at the zero it was
allocated with. This is how XQuartz's keyboard is initialized: model "empty" supplies a symbols section that
defines no keys, and a section that defines nothing is still a section, so XkbInitControls() sees XkmSymbolsMask
and skips its own single-group default. The device only survives because DarwinKeyboardReloadHandler()
immediately pushes a core keymap that raises the count again.
Fixes: https://github.com/XQuartz/XQuartz/issues/422
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2278>
Some amdgpu hardware (older ones, such as AMD Polaris 11 ) can only
render 64x64, 64x128 and 128x128 cursor. It doens't report any errors to
user space and only visual glitches on monitor visible.
This patch checks If drm driver reports any cursor side 64 or 128 - assume
hardware can only render 64x64 or 128x128 hw cursor planes
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1922
Fixes: https://github.com/X11Libre/xserver/issues/1816
(cherry picked from commit 46c411e49b)
(cherry picked from commit 7a0839807111c28b4b1c6728aff4903517277278)
(cherry picked from commit 1f02462d1bb27cd0e61594984af9ccef906079e9)
Signed-off-by: Tautvis <gtautvis@gmail.com>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
exa/exa_accel.c:239:1: warning: ‘inline’ is not at beginning of declaration
[-Wold-style-declaration]
239 | static Bool inline
| ^~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2272>
Wide LineDoubleDash lines drew black on screen under XQuartz while the server's own XGetImage readback showed the
correct pixels, because at depth 24 that readback ignores alpha. Opaque text and dashed arcs take the same path.
fbValidateGC widens a planemask that covers the drawable's depth to cover its full bits per pixel, so the blit and
fill paths can take their all-ones shortcuts. On a rootless server that also writes the alpha channel of the window's
premultiplied surface, which CoreGraphics then composites as black. Rootless keeps that alpha opaque by clearing the
bits from the planemask, but only its own ValidateGC does so, and mi revalidates the GC in the middle of a drawing
operation to swap the foreground for the background pixel. By then the damage layer has unwrapped the rootless funcs
down to fb, so the reassertion never happens and the rest of the operation lands with a zero alpha channel.
Fixes: https://github.com/XQuartz/XQuartz/issues/230
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reported by gcc 16.1:
xkb/xkbUtils.c:1440:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in
the earlier argument and not in the later argument [-Wcalloc-transposed-args]
1440 | dst->geom = calloc(sizeof(XkbGeometryRec), 1);
| ^~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2272>
Providing physical size via RRRegisterSize() is not enough - physical
size is a property of the output, not resolution and needs to be set
separately. Furhermore, get the physical output size using RandR if
-output is used, to match specific output, not the whole screen.
With this, `Xephyr -output OUTPUT_NAME` properly copies not only
resolution but also physical size of the named output.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2240>
xp_frame_draw() renders the window decorations into the frame's backing store from Xplugin's async queue, but
xprFrameDraw() was the only AppleWM handler that did not stop drawing first. When quartz-wm sends AppleWMFrameDraw
while the server still holds the frame locked, Xplugin re-enters the backing lock on an already-locked window and the
backing store is remapped out from under one of the two writers, surfacing as a SIGBUS writing into a read-only CG
backing store mapping.
This removes the self-inflicted overlap and brings the handler in line with its siblings. It narrows the race rather
than closing it: the ordering problem between the async frame draw and the backing lock is tracked separately.
Fixes: https://github.com/XQuartz/XQuartz/issues/352
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
RootlessEnsureFrame returns without releasing a shaped window's region when the implementation refuses to create the
frame, and RootlessMiValidateTree never releases the exposed region it hands to RootlessComputeClips -- upstream
miValidateTree does.
Both are longstanding.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
darwin.c and bundle_trampoline.c wrapped calls that allocate memory, add input devices, or spawn a process in
assert(), so building with NDEBUG would silently skip the call and leave the guarded variable uninitialized or
unset while still proceeding as if it had succeeded.
darwin.c now calls FatalError() on failure. bundle_trampoline runs before the server attaches to a terminal or
console, so stderr is not visible there; it now logs via os_log_error() and calls abort().
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The Cygwin meson runtime resolves to /usr/bin/python3.12.exe (python312 is
pulled in transitively as a meson dependency), while the workflow only
installed python39-lxml. hw/xwin/glx/meson.build therefore failed with
"python3 lxml module not found" on every PR.
Install the lxml module for the Python interpreter meson actually uses.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Apparently KDE's compositor has issues if the dma bufs it sends are imported directly as-is.
Instead, we now create a gbm bo from the dma bufs we receive,
export that as dma bufs, and import those dma bufs.
In the no-gbm case, both when explicitly requested (like Xfbdev),
and when needed (like nvidia-470 which doesn't have official gbm support),
we still use only the faster, non-gbm-based implementation that imports dma bufs directly.
This is effectively a revert of 6b3703e120
on the setups where possible.
As a side effect, DRI3 import might be slightly slower,
hopefully not enough to be noticeable.
Note that it makes no sense to me why this would be needed.
Note also that Xwayland's EGLStream backend was also
importing dma bufs directly:
cac9b20af3/hw/xwayland/xwayland-glamor-eglstream.c (L792)
Fixes: https://github.com/X11Libre/xserver/issues/3262
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
No functional changes intended, those will come in further commits
Slighly modifed during backporting from master.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
dri3 registers it's own screen private, which invalidates
the pointer glamor egl passes.
Caught with asan
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
When using multiple screens with different present capabilities,
we need to store the present screen info for each screen.
Instead of forcing callers to store copies of the screen info struct for each screen,
just copy it in `present_screen_init`
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Treat is the default and copy it for each screen with modifications
slighly modifed due merge conflict.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
sproc_present_pixmap_synced() swapped the fixed request header but, unlike
sproc_present_pixmap(), never byte-swapped the trailing LISTofPRESENTNOTIFY.
present_create_notifies() then read each notify window/serial in the wrong
byte order for swapped clients, so PresentPixmapSynced with notifies resolved
the wrong (or no) window. Bounds are enforced by req_len and dixLookupWindow()
so there was no memory-safety impact, only incorrect behaviour.
Add the missing SwapRestL(stuff).
Fixes: ac0bc0b3b6 ("Present: add PresentCapabilitySyncobj and PresentPixmapSynced")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 16d7c79445)
mask_len is already a byte count (min of the target mask size and
stuff->mask_len * 4), but it was passed to xi2mask_set_one_mask() as
"mask_len * 4", scaling by 4 a second time. With stuff->mask_len == 1 this
made the helper copy 5 bytes from the 4-byte request mask region, a 1-byte
over-read.
Pass mask_len directly, matching the sibling ProcXIGrabDevice().
Fixes: 59a6d7d478 ("Xi: don't overrun memory for grab masks.")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 9d6eae7972)
ProcXTestFakeInput() copies attacker-controlled valuator values into the
fixed-size on-stack array int valuators[MAX_VALUATORS] (MAX_VALUATORS == 36)
when faking an XI DeviceMotionNotify event.
Two flaws allowed a write past the end of that array:
* The initial check used "firstValuator > dev->valuator->numAxes", so
firstValuator == numAxes (legitimately up to 36) was accepted, leaving
base == 36 at the start of the first iteration.
* The per-valuator range check
"firstValuator + numValuators > dev->valuator->numAxes" was performed
*after* the switch that already wrote valuators[base .. base + 5], so the
out-of-bounds write happened before the request was rejected with
BadValue.
A client controlling an XI device with numAxes == 36 could therefore send a
DeviceValuator with first_valuator == 36 and num_valuators in 1..6 and write
up to six attacker-controlled INT32s past the end of the stack buffer.
Tighten the initial check to ">=" and validate num_valuators and the axis
range *before* writing the valuators.
Fixes: 105d28652d ("Xext: use GPE/GKE from XTestFakeInput #16145")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 335fffed92)
sproc_present_pixmap() was missing byte swaps the variable-length
xPresentNotify array after the fixed header was not
byte-swapped at all (each entry has window and serial CARD32 fields).
Fixes: a5ac3c8712 ("present: add missing byte swapping for various fields")
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2202>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit bd03a8d408)
This calls installed default glx vendor at top of callback chain,
which causes problem with other glx vendors, because it always succeds
and set same vendor for screen.
Signed-off-by: Tautvis <gtautvis@gmail.com>
(cherry picked from commit ad1d4a28da)
xf86DisableInputDeviceForVTSwitch() calls seatd_libseat_close_device()
before DisableDevice(), but DisableDevice() is what runs the driver's
DEVICE_OFF. The close has already cleared pInfo->fd and the "fd" option,
so xf86libinput_off() takes its use_server_fd() == false path and
unregisters libinput's epoll fd as -1 -- libinput's fd is never removed
from the input thread.
The stale entry left behind is unrecoverable: a later libinput context
reuses the same fd number and is adopted into it without being re-armed,
so the server ends up with every device enabled but nothing polling
libinput, and all input dies until a restart.
Close the seatd fd after DisableDevice() so pInfo->fd and the "fd"
option are still valid when DEVICE_OFF runs. Upstream releases no fds in
this function at all; the inversion is specific to the seatd integration.
Assisted-by: Claude:claude-opus-5
Signed-off-by: galternat <galternat.twins223@simplelogin.com>
(cherry picked from commit 2e9520df2f)
Commit a987fc7c36 linked glx library
statically, which leaded dublicated glx extension symbols in glx.so and
glamoregl.so libraries. This commit do not link glx directly.
Signed-off-by: Tautvis <gtautvis@gmail.com>
(cherry picked from commit 6c75731752)
In a987fc7c36 commit glx library is
statically linked which makes all glx library variables dublicated in
glx.so and glamoregl.so files and leads 'split-brain' problem where same
symbols exist in different depending on context (this evident when it
called using functions with static attribute).
This patch exports neccesary glx symbols for glamor library.
Signed-off-by: Tautvis <gtautvis@gmail.com>
(cherry picked from commit 9b74a3a7f9)
With commit b5141a1fab (2014-07-22,
"xfree86: Simplify a bunch of OS and arch conditionals"), the MIPS
port I/O and MMIO code has been incorrectly nested inside the
`#elif defined(__arm32__) && !defined(__linux__)` - thus impossible
to ever become active.
Ergo: MIPS support was broken all the time, Xservers compiled on MIPS
lacked basic IO support.
Fixes: b5141a1fab
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 149291a002)
On a calloc() failure while growing the rootless screen pixmap buffer, the
old buffer was already freed and pixmap_data_size already bumped to the new
(larger) size before the failure check -- leaving s->pixmap_data (and the
screen pixmap pPix, still pointing at the freed block via its prior
ModifyPixmapHeader() call) dangling. Worse, because pixmap_data_size was
already bumped, a later same-or-smaller-size call sees pixmap_data_size <
rowbytes as false and skips reallocating forever, permanently pinning the
dangling state instead of retrying.
Trigger: real host memory pressure during a rootless (Xquartz-style DDX)
geometry change.
Fix: allocate the replacement into a temporary first; only free the old
buffer and update pixmap_data_size/pixmap_data together once the new
allocation has succeeded.
Found via a fleet-directed alloc-fail/UAF sweep of Xext/, mi/, and miext/,
not from a live crash report. Verification note: miext/rootless/ only
compiles into hw/xquartz, which this Linux build has disabled -- checked
with a standalone `gcc -fsyntax-only` pass instead of the normal
ninja+meson-test build/test cycle used for the other fixes in this sweep.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit d536dde7b4)
miDCInitialize() registers the CloseScreen hook (miDCCloseScreen, via
dixScreenHookPostClose()) and stores pScreenPriv into the screen's
devPrivates *before* calling miSpriteInitialize(). On failure it only
freed pScreenPriv, leaving both the hook armed and the devPrivates slot
pointing at now-freed memory.
This isn't just "a caller that ignores the Bool return could look it up
later" -- the hook it already registered guarantees the problem fires on
every subsequent screen close: miDCCloseScreen() looks up the dangling
pointer via dixLookupPrivate(), passes it to miDCSwitchScreenCursor()
(dereferencing freed memory, e.g. dixDestroyPixmap() on
pScreenPriv->sourceBits), and then frees pScreenPriv a second time.
Trigger: any allocation failure inside miSpriteInitialize() during screen
init (a DDX like vfb/kdrive/xfree86/xnest/xwin calling miDCInitialize())
sets this up; the actual crash fires later, at screen close.
Fix: unhook the CloseScreen callback and clear the devPrivates slot before
freeing pScreenPriv, matching what miDCCloseScreen() itself does on the
normal teardown path.
Found via a fleet-directed alloc-fail/UAF sweep of Xext/, mi/, and miext/,
not from a live crash report.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 2ba0ed012f)
The reply struct was declared bare (uninitialised auto storage) and then
filled field-by-field (red/green/blue/pixel only), leaving pad1/pad2 and
any trailing padding uninitialised. Those bytes were then sent to the
client via X_SEND_REPLY_SIMPLE, an information disclosure.
Fix it with a designated initialiser so the pad/reserved bytes are
zeroed. This block sits inside XINERAMA_FOR_EACH_SCREEN_BACKWARD(), which
took a single macro parameter — so a top-level '{ .a = x, .b = y }'
initialiser was split at its commas into multiple macro arguments (the
old "static init would confuse preprocessor" caveat). Rather than work
around that per call site, make the XINERAMA_FOR_EACH_SCREEN_* macros
variadic (pass the body as __VA_ARGS__); commas in the body are then
preserved, and an ordinary designated initialiser can be used with no
compound-literal cast or extra parentheses.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 7badd1eec2843eb060d569b4b4cc36545c67cdd2)
The reply struct was declared bare (uninitialised auto storage) and then
filled field-by-field (majorVersion/minorVersion only), leaving pad1 and
any trailing padding uninitialised. Those bytes were then sent to the
client via X_SEND_REPLY_SIMPLE, an information disclosure.
Use a designated initialiser so all omitted fields and padding are zeroed;
type/sequenceNumber/length are still set by X_SEND_REPLY_SIMPLE afterward.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit f045ee09ad)
rrGetMultiScreenResources() and rrGetScreenResources() copy each mode name
with its exact length while the reply payload length rounds the total name
bytes up to a 4-byte multiple. The trailing alignment padding was left
uninitialized because the buffer was allocated with the non-zeroing
x_rpcbuf_reserve(), disclosing server heap to the client.
Use x_rpcbuf_reserve0() for both extra buffers.
Fixes: cbc4e91f02 ("randr: rrGetMultiScreenResources(): use x_rpcbuf_t")
Fixes: 26a1e5f709 ("randr: rrGetScreenResources(): use x_rpcbuf_t")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 88332a2a52)
ProcRenderQueryPictFormats left the internal padding of xPictFormInfo (pad1)
and xPictDepth (pad1, pad2) unwritten, and ProcRenderQueryFilters left the
odd-count alias alignment slot and the filter-name alignment tail unwritten.
Both reply buffers were allocated with the non-zeroing x_rpcbuf_reserve(), so
those bytes disclosed uninitialized server heap to the client.
Use x_rpcbuf_reserve0() for both reply payloads.
Fixes: fe9fcfe98f ("render: ProcRenderQueryPictFormats(): use x_rpcbuf_t")
Fixes: 81f93d19a0 ("render: ProcRenderQueryFilters(): use x_rpcbuf_t")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit d6c0b230e8)
The xvImageFormatInfo records in the ProcXvListImageFormats reply left the
inter-field padding (pad1..pad10, ~18 bytes per format) uninitialized: it was
reserved with the non-zeroing x_rpcbuf_reserve() and never written, so those
bytes were sent to the client as uninitialized server heap.
Write the padding fields explicitly as zero with x_rpcbuf_write_CARD8/16/32(),
matching the field-by-field construction of the rest of the record.
Fixes: 2d66d11caf ("Xext: xv: ProcXvListImageFormats(): use x_rpcbuf_t for reply payload assembly")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 92e1be28ec)
The reply "extra" buffer was allocated with the non-zeroing
x_rpcbuf_reserve(), and the provider name is copied with
memcpy(name, provider->name, reply.nameLength). Because the reserved length
rounds nameLength up to a 4-byte multiple, the up-to-3 trailing padding bytes
after the name were left uninitialized and sent to the client (e.g. for
"modesetting", nameLength 11), disclosing heap memory.
Use x_rpcbuf_reserve0() to zero the buffer.
Fixes: 36ef6a448b ("randr: ProcRRGetProviderInfo(): use x_rpcbuf_t")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 16547f561d)
The reply payload was allocated with the non-zeroing x_rpcbuf_reserve(), and
the CopySwapKbdFeedback/CopySwapPtrFeedback/CopySwapBellFeedback helpers
populate every field except the internal pad bytes of xKbdFeedbackState (1),
xPtrFeedbackState (2) and xBellFeedbackState (3). Those pad bytes were sent to
the client verbatim, disclosing uninitialized heap memory.
Use x_rpcbuf_reserve0() to zero the buffer, restoring the behaviour that the
earlier calloc()-based code provided before the x_rpcbuf conversion.
Fixes: 6413bd61d7 ("Xi: ProcXGetFeedbackControl(): use x_rpcbuf_t")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit ed18fc7d1c)
ReadXkmIndicators() used the wire.indicator byte (CARD8, 0..255) as
indicators[wire.indicator - 1] and maps[wire.indicator - 1] without any range
check. Both arrays have XkbNumIndicators (32) entries, so indicator == 0
(index -1) or indicator > 32 wrote past the array bounds.
The parsed .xkm data is produced by the server's own xkbcomp on a stock
build, so this is hardening rather than a directly client-reachable bug, but
the sibling readers (ReadXkmKeycodes, ReadXkmKeyTypes) already validate their
indices and ReadXkmGeometry was fixed for the same class in 5d7e34fc9e.
Reject out-of-range indicator values.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 0d5163c73d)
The handler deliberately continues when dixLookupDevice() returns BadAccess
(to emit class headers with the device state blanked out). However
dixLookupDevice() leaves *pDev == NULL on any non-Success return, so the
subsequent "v = dev->valuator" dereferenced NULL and crashed the server.
This is reachable when an XACE/SELinux hook denies the client's DixReadAccess
to the device. Bail out when dev is NULL instead of dereferencing it.
Fixes: 8502c06e19 ("xace: Fake return values on denials in input polling requests.")
Fixes: 5c03d13181 ("xace: add new hooks + access controls: XInput extension.")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit a12b92d4b6)
convolutionFilterValidateParams() derives w/h from client-supplied
xFixed values via the sign-extending xFixedToInt(), then checked
'w * h > nparams' as a plain (signed) int product. A client can choose
negative w/h so the mathematical product is huge but the signed int
product wraps to a small or negative value, defeating the bounds check
that is supposed to reject a convolution kernel larger than the actual
parameter list.
Reject negative w/h outright and compare the product as int64_t so it
cannot wrap before the comparison.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@vnc.biz>
(cherry picked from commit 6a97f6d38e)
The per-mask loop read evmask->mask_len to compute the next mask's
length before checking that the fixed xXIEventMask header itself was
still within the request buffer - a request with num_masks >= 1 and
insufficient trailing data reads one xXIEventMask-header's worth past
the end of the request. The byte-swapped path just above already
performs the equivalent pre-check ('len < bytes_to_int32(sizeof
(xXIEventMask))') before touching evmask->mask_len; this brings the
non-swapped path in line with it.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@vnc.biz>
(cherry picked from commit bf6b62648d)
