- C 94.2%
- Python 2.2%
- Roff 1.2%
- Objective-C 1%
- Meson 0.9%
- Other 0.3%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
bae088ccbd
CheckKeySyms() has two loops: the first processes keys in the SetMap
request range, the second fills in any missing keys from the existing
map.
The indexing between the two was inconsistent: the first loop
uses a zero-based index + req->firstKeySym, the second loop used it just
as zero-based index.
Example:
req->firstKeySym = 50
req->nKeySyms = 10
i goes from 0 to 10,
loop 1 checks [50, 60), changes the width but finishes with i at 10.
loop 2 then runs over [10, 255(, copying the old keymap width
The second loop overwrites the new widths with the width of the
existing keymap. The subsequent SetKeySyms worked on the new width
and may write fewer actions than the map width.
A subsequent XkbGetMap request would then read XkbKeyNumActions()
entries (derived from the new wider key_sym_map.width) from the shorter
action allocation, causing an out-of-bounds heap read. The overread
bytes would be copied into the GetMap reply and sent back to the client,
producing a bounded heap information disclosure.
This vulnerability was discovered by:
WONJOON HWANG (@joon1337) working with TrendAI Zero Day Initiative
ZDI-CAN-32408
CVE-2026-93524
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit
|
||
| .github | ||
| .vscode | ||
| config | ||
| dix | ||
| doc | ||
| exa | ||
| fb | ||
| glamor | ||
| hw | ||
| include | ||
| man | ||
| mi | ||
| miext | ||
| msutil | ||
| os | ||
| test | ||
| Xext | ||
| .clang-tidy | ||
| .dir-locals.el | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .mailmap | ||
| CoC.md | ||
| CODE_OF_CONDUCT.md | ||
| CODE_OVERVIEW.md | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| HISTORY.md | ||
| meson.build | ||
| meson_options.txt | ||
| NEWS | ||
| README.md | ||
| xlibre-server.pc.in | ||
| xorg-server.m4 | ||
| xorg-server.pc.in | ||
| xserver.ent.in | ||
XLibre Xserver
The XLibre Xserver is the community-managed display server for the X Window System Protocol Version 11 (Wikipedia), in short, X11.
Selected Features
- All the good things from X.Org Server, including its unreleased features
- TearFree modesetting by default and optionally atomic modesetting
- Support for the Nvidia drivers 340, 390, 470, 570, and newer
- Xnamespace extension for separating X clients
- Support for seat management via seatd besides systemd-logind
- Xfbdev, the generic framebuffer Xserver for Linux
- CI builds for several BSDs, Linux, MacOS, and Microsoft Windows
- Active community, cleanups, fixes, and development based on merit
To learn more about the features and mission of XLibre, please visit our homepage.
Switching to XLibre
The easiest way to install and run XLibre is to use your distribution's provided packages. Please see the Are We XLibre Yet? - (X11Libre/xserver Wiki) page for a list of the available options. If there is no option, then go on with building and installing XLibre from source.
Building XLibre
After cloning the Xserver repository or unpacking the sources and installing the dependencies, change into the source directory and run the Meson build tool:
cd "<source dir of xserver>"
meson setup <prefix> build <meson_options>
ninja -C build install
You may specify the install <prefix> with, for example, --prefix="$(pwd)/image" and add build time <meson_options> like so: -Dxnest=false. You may also want to build and install some graphics and input drivers. Please refer to the Building XLibre (X11Libre/xserver Wiki) page for more details.
Configuring XLibre
Until XLibre releases its own, you can find a detailed description of the configuration on the Configuration - Xorg (ArchWiki) page. If you have built and installed XLibre yourself, then change into the <prefix> directory with cd <prefix> and create a directory etc/X11 with a file xorg.conf and adjust it accordingly.
Starting with version 25.0.0.16, the proprietary Nvidia driver is autodetected and handled internally without any special configuration. Please see the Compatibility of XLibre (X11Libre/xserver Wiki) page for more details on the Nvidia driver and compatibility in general.
Running XLibre
If you installed XLibre using your distribution's provided packages, then the Xserver is usually started by init (Wikipedia) on system start. On other systems it should be possible to manually start XLibre with user permissions by invoking startx. Please refer to man startx for how to use it.
If you have built and installed XLibre yourself, then you may want to shutdown other Xservers, change into the <prefix> directory, and create a simple testx.sh file with the following contents:
#!/bin/sh
./bin/X :1 vt8 -logfile /dev/stdout &
_pid=$!
sleep 10 && kill $_pid
You can adjust the :1 vt8 and other options in the testx.sh file as detailed in man Xorg. Make the testx.sh executable and run it:
chmod 0770 testx.sh
./testx.sh
This should give you 10 glorious seconds of a black and beautiful and empty screen. Afterwards the Xserver complains about being killed, but there should be no other critical errors for a "test passed." For more details, please see Building XLibre (X11Libre/xserver Wiki).
If you are using seatd for rootless operation instead of (e)logind, create the following file named .xserverrc in your home directory:
#!/bin/sh
exec X -keeptty "$@"
Then, run chmod +x ~/.xserverrc.
I want to help!
That's great; there's enough to do for everyone. You may consider one of the many ideas and feature requests out there. To help in testing, you may consider becoming an XLibre Test Driver. Please also have a look at the good first and help wanted issues and the Liberated Screens.
If you want to work on anything, just let us know. If you have any questions, just ask. Thank you!
Contact
XLibre Discussions at GitHub | XLibre mailing list at FreeLists | @x11dev channel at Telegram | #xlibredev space at Matrix | XLibre security contact at GitHub