1af7e6c89d
Previously we leaked stack when invalid enum parameters were
specified and caused __glGet*_size functions to return a 0 size.
Further, we read out-of-bounds (and leaked) when the input data was less
than 8 bytes (__glXDispSwap_GetFramebufferAttachmentParameteriv and
__glXDisp_GetRenderbufferParameteriv).
Now we only write a single element in the reply padding, and only when there
is a single element. This is what the Mesa client-side libGL expects, and
restores original GLX server behaviour, matching both pre-public (1996) SGI GLX
and XFree86 4.
The main risk of this change is if we have any error in element count or size;
previously it may not have mattered but now it does.
There are no piglit result changes from this modification using either mesa
libGLX or NVIDIA libGLX.
For performance considerations, an extra conditional and variable-length
memcpy has no meaningful impact on the indirect rendering pipeline cost.
There is still the possiblity to leak if our size checks allow an enum that
the GL implemention does not. Guarding against that requires zero-initializing
all temp storage, which wants re-evaluation of the blind 200-byte buffers
used for many calls and thus is a much bigger change.
Signed-off-by: Nathan Kidd <nkidd@rocketsoftware.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1647>
(cherry picked from commit
|
||
|---|---|---|
| .gitlab-ci | ||
| composite | ||
| config | ||
| damageext | ||
| dbe | ||
| dix | ||
| doc | ||
| dri3 | ||
| exa | ||
| fb | ||
| glamor | ||
| glx | ||
| hw | ||
| include | ||
| man | ||
| mi | ||
| miext | ||
| os | ||
| present | ||
| pseudoramiX | ||
| randr | ||
| record | ||
| render | ||
| test | ||
| Xext | ||
| xfixes | ||
| Xi | ||
| xkb | ||
| .appveyor.yml | ||
| .dir-locals.el | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| COPYING | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
| xorg-server.m4 | ||
| xorg-server.pc.in | ||
| xserver.ent.in | ||
X Server
The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens" that the client program can draw into.
Windows are then composed on the actual screen by the X server (or by a separate composite manager) as directed by the window manager, which usually communicates with the user via graphical controls such as buttons and draggable titlebars and borders.
For a comprehensive overview of X Server and X Window System, consult the following article: https://en.wikipedia.org/wiki/X_server
All questions regarding this software should be directed at the Xorg mailing list:
https://lists.freedesktop.org/mailman/listinfo/xorg
The primary development code repository can be found at:
https://gitlab.freedesktop.org/xorg/xserver
For patch submission instructions, see:
https://www.x.org/wiki/Development/Documentation/SubmittingPatches
As with other projects hosted on freedesktop.org, X.Org follows its Code of Conduct, based on the Contributor Covenant. Please conduct yourself in a respectful and civilized manner when using the above mailing lists, bug trackers, etc: