a4df686888
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> |
||
|---|---|---|
| .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: