Fixes the following security issues:
- CVE-2024-57970: libarchive through 3.7.7 has a heap-based buffer
over-read in header_gnu_longlink in archive_read_support_format_tar.c
via a TAR archive because it mishandles truncation in the middle of a
GNU long linkname.
For more information, see:
- https://nvd.nist.gov/vuln/detail/CVE-2024-57970
- 8291210321
- CVE-2025-1632: This affects the function list of the file bsdunzip.c.
The manipulation leads to null pointer dereference. It is possible
to launch the attack on the local host.
For more information, see:
- https://nvd.nist.gov/vuln/detail/CVE-2025-1632
- c9bc934e7e
- CVE-2025-25724: list_item_verbose in tar/util.c in libarchive through 3.7.7
does not check an strftime return value, which can lead to a denial of
service or unspecified other impact via a crafted TAR archive that is read
with a verbose value of 2.
For example, the 100-byte buffer may not be sufficient for a custom locale.
For more information, see:
- https://nvd.nist.gov/vuln/detail/CVE-2025-25724
- c9bc934e7e
The patch added in [1] are still needed for this version bump.
For more details on the version bump, see the release notes:
- https://github.com/libarchive/libarchive/releases/tag/v3.7.8
- https://github.com/libarchive/libarchive/releases/tag/v3.7.9
[1] 9ac63a3360 package/libarchive: fix uclibc build with libiconv (again)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fde0b3fe1c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security issue:
- CVE-2025-2588: This vulnerability affects the function
re_case_expand of the file src/fa.c. The manipulation of the
argument re leads to null pointer dereference
For more information, see:
- https://nvd.nist.gov/vuln/detail/CVE-2025-2588
- af2aa88ab3
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Julien: add patch name in comment near _IGNORE_CVES]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c497e5fcc7)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The patch introduced in [1] that fixed the CVE-2024-0962 is now
available upstream in the 4.3.5 release [2].
This commit also updates the LICENSE file hash, after adding reference
to wolfSSL in [3].
For more details see the release note:
https://github.com/obgm/libcoap/blob/v4.3.5/ChangeLog
[1] 9002b818be package/libcoap: fix CVE-2024-0962
[2] 2b28d8b0e9
[3] e3a662a934
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Julien: fix LICENSE file hash]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4df4d1d312)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
No functional change, but bump for consistency.
The patch that was applied by Buildroot has been applied to gstreamer.
The kate plugin has disappeared from gstreamer.
The webp plugin now requires webp_mux to compile.
The webrtc plugin now requires to be compile with plugins dtls, sctp and
srtp.
For more details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.24/
Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 90b3cfedf4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Tested on QEMU using the qemu_m68k_q800_defconfig configuration, with a
switch of the toolchain to uclibc-ng and enabling rsyslog.
This patch addresses an issue where rsyslog’s pthread_cond_wait was
busy-looping due to futex_time64 repeatedly returning EINVAL. The
correction in NPTL alignment resolves the 100% CPU usage problem.
This patch is fixed upstream [1] so apply it until it is tagged.
[1]: 278ac6b30 ("m68k: fix alignment in NPTL code")
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
[Julien:
- rename patch to 0002
- add "Upstream:" tag in patch to fix check-package error
- add "Signed-off-by:" in patch
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 53eae986a5)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
uClibc-ng unconditionally exposes a reallocarray() prototype, but only
provides the implementation when the malloc-standard implementation is
selected in the configuration.
As noMMU configurations can't use malloc-standard, they use malloc or
malloc-simple that don't provide reallocarray().
As a result of reallocarray() being missing, some packages such as
util-linux provide their own replacement implementation... but its
prototype clashes with the one provided by uClibc, causing build
failures such as:
In file included from lib/color-names.c:7:
./include/c.h:586:21: error: static declaration of ‘reallocarray’ follows non-static declaration
586 | static inline void *reallocarray(void *ptr, size_t nmemb, size_t size)
| ^~~~~~~~~~~~
In file included from ./include/c.h:16:
/home/thomas/projets/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/sysroot/usr/include/stdlib.h:898:14: note: previous declaration of ‘reallocarray’ with type ‘void *(void *, size_t, size_t)’ {aka ‘void *(void *, unsigned int, unsigned int)’}
898 | extern void *reallocarray (void *__ptr, size_t __m, size_t __n);
| ^~~~~~~~~~~~
make[3]: *** [Makefile:12354: lib/libtcolors_la-color-names.lo] Error 1
This is addressed by a patch on uClibc, submitted upstream, which
makes sure the prototype is only exposed when the implementation is
provided.
The issue can be reproduced with commands:
cat <<EOF >.config
BR2_arm=y
BR2_cortex_m4=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PACKAGE_UTIL_LINUX=y
BR2_PACKAGE_UTIL_LINUX_KILL=y
EOF
make olddefconfig
make util-linux
Fixes:
https://autobuild.buildroot.net/results/157aa82aa4cd57eacc4defe6cace16e464261e9a/ (RISC-V noMMU)
https://autobuild.buildroot.net/results/ce1a24c1465b82686ae375ac688a553fb65df5ea/ (ARM noMMU)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Julien: add commands to reproduce the issue in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 01895663d3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
glibc fails to build on RISC-V 32-bit with the ilp32f ABI and on
RISC-V 64-bit with the lp64f: both use single-point precision floating
point, which glibc doesn't support, failing during the configure step
with:
configure: error: glibc does not yet support the single floating-point ABI
Fix that by disabling glibc support on those configurations.
Fixes:
https://autobuild.buildroot.org/results/fe8d569cab507992978ef0da649278dd3a9e0b23/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8292b8fb89)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Use the 'C' locale when retrieving the date of the last change using
'svn info' since the svn download helper script expect
"Last Changed Date" string.
If another locale is used, the 'date' is empty so the generated
archive (by mk_tar_gz) will not match the expected hash since
the file timestamp is not set properly.
If LANG=fr_FR.UTF-8 is defined in the host system, svn print some
"French encrypted" text:
eval svn --non-interactive --config-option servers:global:http-timeout=10 info ''\''https://svn.code.sf.net/p/xmlrpc-c/code/advanced@r3176'\'''
...
Date de la dernière modification: 2023-09-02 19:13:35 +0200 (sam. 02 sept. 2023)
diffoscope confirm that the file timestamp is not set correctly
in the generated archive:
$ diffoscope NOK/libxmlrpc-r3176-svn5.tar.gz OK/libxmlrpc-r3176-svn5.tar.gz
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8d3b1781f6)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security issue:
CVE-2025-27091: OpenH264 Decoding Functions Heap Overflow Vulnerability
A vulnerability in the decoding functions of OpenH264 codec library could
allow a remote, unauthenticated attacker to trigger a heap overflow.
This vulnerability is due to a race condition between a Sequence Parameter
Set (SPS) memory allocation and a subsequent non Instantaneous Decoder
Refresh (non-IDR) Network Abstraction Layer (NAL) unit memory usage. An
attacker could exploit this vulnerability by crafting a malicious bitstream
and tricking a victim user into processing an arbitrary video containing the
malicious bitstream. An exploit could allow the attacker to cause an
unexpected crash in the victim's user decoding client and, possibly, perform
arbitrary commands on the victim's host by abusing the heap overflow.
https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9xhttps://github.com/cisco/openh264/releases/tag/2.5.1
The upstream tag now has no 'v' prefix, so drop it from _SITE.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a7aeb5a46e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
23.2.5 fixes the following security issues:
1) CVE-2024-31080: Heap buffer overread/data leakage in ProcXIGetSelectedEvents
Introduced in: xorg-server-1.7.0 (2009)
Fixed in: xorg-server-21.1.12 and xwayland-23.2.5
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/96798fc1967491c80a4d0
Found by: Alan Coopersmith of Oracle Solaris, while investigating
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762
The ProcXIGetSelectedEvents() function uses the byte-swapped length of the
return data for the amount of data to return to the client, if the client
has a different endianness than the X server.
2) CVE-2024-31081: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice
Introduced in: xorg-server-1.7.0 (2009)
Fixed in: xorg-server-21.1.12 and xwayland-23.2.5
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/3e77295f888c67fc7645d
Found by: Alan Coopersmith of Oracle Solaris
The ProcXIPassiveGrabDevice() function uses the byte-swapped length of the
return data for the amount of data to return to the client, if the client
has a different endianness than the X server.
3) CVE-2024-31083: User-after-free in ProcRenderAddGlyphs
Introduced in: prior to X11R6.7 (2004)
Fixed in: xorg-server-21.1.12 and xwayland-23.2.5
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bdca6c3d1f5057eeb3160
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The ProcRenderAddGlyphs() function calls the AllocateGlyph() function
to store new glyphs sent by the client to the X server. AllocateGlyph()
would return a new glyph with refcount=0 and a re-used glyph would end up
not changing the refcount at all. The resulting glyph_new array would thus
have multiple entries pointing to the same non-refcounted glyphs.
ProcRenderAddGlyphs() may free a glyph, resulting in a use-after-free when
the same glyph pointer is then later used.
https://lists.x.org/archives/xorg-announce/2024-April/003497.html
24.1.4 fixes the following security issues:
1) CVE-2024-9632: Heap-based buffer overflow privilege escalation in
_XkbSetCompatMap
Introduced in: xorg-server-1.1.1 (2006)
Fixed in: xorg-server-21.1.14 and xwayland-24.1.4
Fix:
85b7765714
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The _XkbSetCompatMap() function attempts to resize the `sym_interpret`
buffer.
However, It didn't update its size properly. It updated `num_si` only,
without updating `size_si`.
This may lead to local privilege escalation if the server is run as root
or remote code execution (e.g. x11 over ssh).
xorg-server-21.1.14 and xwayland-24.1.4 have been patched to fix this issue.
https://lists.x.org/archives/xorg-announce/2024-October/003545.html
24.1.6 fixes the following security issues:
1) CVE-2025-26594: Use-after-free of the root cursor
Introduced in: Unknown - Prior to X11R6.6 Xorg baseline
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/01642f26https://gitlab.freedesktop.org/xorg/xserver/-/commit/b0a09ba6
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The root cursor is referenced in the xserver as a global variable. If
a client manages to free the root cursor, the internal reference points
to freed memory and causes a use-after-free.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
2) CVE-2025-26595: Buffer overflow in XkbVModMaskText()
Introduced in: Prior to X11R6.1
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/11fcda87
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the names of the virtual modifiers to that buffer.
The code however fails to check the bounds of the buffer correctly and
would copy the data regardless of the size, which may lead to a buffer
overflow.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
3) CVE-2025-26596: Heap overflow in XkbWriteKeySyms()
Introduced in: initial version of xc/programs/Xserver/xkb/xkb.c in X11R6
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/80d69f01
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), which may lead to a heap based
buffer overflow.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
4) CVE-2025-26597: Buffer overflow in XkbChangeTypesOfKey()
Introduced in: X11R6.1
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/0e4ed949
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
If XkbChangeTypesOfKey() is called with 0 group, it will resize the key
symbols table to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value of groups,
this will cause a buffer overflow because the key actions are of the wrong
size.
5) CVE-2025-26598: Out-of-bounds write in CreatePointerBarrierClient()
Introduced in: xorg-server-1.14.0
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bba9df1a
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The function GetBarrierDevice() searches for the pointer device based on
its device id and returns the matching value, or supposedly NULL if no
match was found.
However the code will return the last element of the list if no matching
device id was found which can lead to out of bounds memory access.
6) CVE-2025-26599: Use of uninitialized pointer in compRedirectWindow()
Introduced in: Xorg 6.8.0.
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/c1ff84behttps://gitlab.freedesktop.org/xorg/xserver/-/commit/b07192a8
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The function compCheckRedirect() may fail if it cannot allocate the backing
pixmap. In that case, compRedirectWindow() will return a BadAlloc error
without the validation of the window tree marked just before, which leaves
the validate data partly initialized, and the use of an uninitialized pointer
later.
7) CVE-2025-26600: Use-after-free in PlayReleasedEvents()
Introduced in: X11R5
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/6e0f332b
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
When a device is removed while still frozen, the events queued for that
device remain while the device itself is freed and replaying the events
will cause a use after free.
8) CVE-2025-26601: Use-after-free in SyncInitTrigger()
Introduced in: X11R6
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/16a1242dhttps://gitlab.freedesktop.org/xorg/xserver/-/commit/f52cea2fhttps://gitlab.freedesktop.org/xorg/xserver/-/commit/8cbc90c8https://gitlab.freedesktop.org/xorg/xserver/-/commit/c2857989
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
When changing an alarm, the values of the change mask are evaluated one
after the other, changing the trigger values as requested and eventually,
SyncInitTrigger() is called.
If one of the changes triggers an error, the function will return early,
not adding the new sync object.
This can be used to cause a use after free when the alarm eventually
triggers.
https://lists.x.org/archives/xorg-announce/2025-February/003584.html
Drop now removed xwayland_eglstream option:
701284f057
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 57d2bdb123)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit f2a862fe60 (package/dillo: move to github) changed the source
site for the Dillo package. This change introduced a trailing slash at
the end of the URL.
This cause an error when running `make show-info` with `BR2_PACKAGE_DILLO=y`:
```
package/dillo/dillo.mk:46: *** DILLO_SITE (https://github.com/dillo-browser/dillo/releases/download/v3.0.5/) cannot have a trailing slash. Stop.
```
This commit removes the trailing slash.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a3b4ae2eac)
Fixes the following security issues:
- CVE-2024-24258: freeglut 3.4.0 was discovered to contain a memory leak
via the menuEntry variable in the glutAddSubMenu function.
- CVE-2024-24259: freeglut through 3.4.0 was discovered to contain a
memory leak via the menuEntry variable in the glutAddMenuEntry
function.
https://nvd.nist.gov/vuln/detail/CVE-2024-24258https://nvd.nist.gov/vuln/detail/CVE-2024-24259
The CVEs are not technically reported for the libfreeglut package
itself (which doesn't have a CPE identifier) but for mupdf.
Note that mudpf provides its own (old) version of freeglut, but our
mupdf package uses the Buildroot-provided freeglut (which now contains
the fix).
It also has to be noted that a more recent release of libfreeglut
exists upstream, and it fixes the same CVEs. Bumping our package
version however requires more work that can be done separately.
Including this patch first also has the advantage that it can easily
be backported wherever it's needed.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 0f4fef076f)
FreeRDP fails to build on newer gcc:
/freerdp-2.11.7/libfreerdp/core/info.c:88:39: error: initialization of 'const WCHAR *' {aka 'const short unsigned int *'} from incompatible pointer type 'BYTE *' {aka 'unsigned char *'} [-Wincompatible-pointer-types]
88 | const WCHAR* domain = Stream_Pointer(s);
| ^~~~~~~~~~~~~~
There is a patch upstream [0] to fix that one, but then another similar
build failure triggers, which is also fixed upstream, but then a third
failre triggers, again fixed upstream [2], but then...
FreeRDP 2.x has been kinda discontinued, and the new stable is 3.x.
However, bumping to 3.x looks like a huge leap.
So, rather than backport, just bump to the latest commit on the
stable-2.0 branch, which carries 12 non-merge commits with build fixes:
562ae3588 [winpr,pubsub] add NULL parameter checks
68c7c21b9 X11 client: ignore grab related LeaveNotify events
a9deecc99 fix [core]: 'invalid hHandle' errors
052c525e0 [core] eliminate rdpRdp::instance
be23ed4ba [server,proxy] deactivate capture module
5b2b53b15 [warnings] fix -Wincompatible-pointer-types
67818bddb [client,wayland] fix const correctness
d2b6771c7 X11: fix pointer/integer type mismatch
[2] 7894a7dfc redirection: Fix incompatible pointer type
[1] f3ed1f1ac redirection: Fix incompatible pointer type
[0] 4f411197d info: Fix incompatible pointer type
a383740a2 next-dev-2.11.8-dev
Fixes:
http://autobuild.buildroot.org/results/e1b/e1b95b4fb0005d4e933b027b508cec9ad510bd73/http://autobuild.buildroot.org/results/ba0/ba0beae13e1be2573878ee50b1566f4427b269a3/
...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 15f15cfe01)
The libcap Makefile is hand-coded (i.e. not autotools), and hard-codes
calls to /sbin/ldconfig, unless it is installed out-of-tree. For target
packages, this is done, but for host package this is not done, as we
do set PREFIX instead, which causes libcap's Makefile to call ldconfig
and emits a spurious warning (twice):
install -m 0755 libcap.so.2.73 /home/ymorin/dev/buildroot/O/master/per-package/host-libcap/host/lib/libcap.so.2.73
ln -sf libcap.so.2.73 /home/ymorin/dev/buildroot/O/master/per-package/host-libcap/host/lib/libcap.so.2
ln -sf libcap.so.2 /home/ymorin/dev/buildroot/O/master/per-package/host-libcap/host/lib/libcap.so
/sbin/ldconfig
/sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
make[4]: [Makefile:200: install-shared-cap] Error 1 (ignored)
This is just a warning, but it is incorrect still.
Fake an out-of-tree install with a non-empy DESTDIR that is just '/',
and thus does in fact not install out-of-tree. This is enough to
actually silence the warning. Add a little comment to explain that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Bernd Kuhls <bernd@kuhls.net>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e172bb48d3)
Since upstream commit [1] the original v4l2loopback-ctl bash script was
replaced by a C version, so add a proper compile step (and remove bash
runtime dependency) to fix '[help] v4l2loopback package build fails for
raspberrypi5' [2].
The issue can be reproduced with the commands:
cat <<EOF >.config
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_PACKAGE_V4L2LOOPBACK=y
BR2_PACKAGE_V4L2LOOPBACK_UTILS=y
EOF
make olddefconfig
make v4l2loopback
Note: upstream commit [1] was introduced in version v0.13.0.
Buildroot bumped v4l2loopback to v0.13.2 in [3].
Fixes:
/usr/bin/install: cannot stat
'.../build/v4l2loopback-0.13.2/utils/v4l2loopback-ctl':
No such file or directory
[1] 33922fa4e9
[2] https://lists.busybox.net/pipermail/buildroot/2025-March/775911.html
[3] 02540771bc
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[Julien:
- add commands to reproduce the issue
- add reference to buildroot commit introducing the issue
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5d85d23e16)
This is a corrective release over GDB 16.1, fixing the following issues:
PR build/32578 (cannot build GDB 16.1 out of tree when calling the configure script with a relative path)
PR tui/32592 ([gdb/tui] internal error in tui-winsource.c:340:refresh_window)
PR remote/32593 (Incompatibilities between GDB's and LLDB's 'x' packet implementation)
PR build/32610 (Missing #include file in darwin_nat.c)
None of which is really super important for Buildroot, but at least
we're using the latest without wondering why we're not.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 0a5a0772c2)
21.1.14 fixes the following security issues:
1) CVE-2024-9632: Heap-based buffer overflow privilege escalation in
_XkbSetCompatMap
Introduced in: xorg-server-1.1.1 (2006)
Fixed in: xorg-server-21.1.14 and xwayland-24.1.4
Fix:
85b7765714
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The _XkbSetCompatMap() function attempts to resize the `sym_interpret`
buffer.
However, It didn't update its size properly. It updated `num_si` only,
without updating `size_si`.
This may lead to local privilege escalation if the server is run as root
or remote code execution (e.g. x11 over ssh).
xorg-server-21.1.14 and xwayland-24.1.4 have been patched to fix this issue.
https://lists.x.org/archives/xorg-announce/2024-October/003545.htmlhttps://lists.x.org/archives/xorg-announce/2024-October/003546.html
21.1.16 fixes the following security issues:
1) CVE-2025-26594: Use-after-free of the root cursor
Introduced in: Unknown - Prior to X11R6.6 Xorg baseline
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/01642f26https://gitlab.freedesktop.org/xorg/xserver/-/commit/b0a09ba6
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The root cursor is referenced in the xserver as a global variable. If
a client manages to free the root cursor, the internal reference points
to freed memory and causes a use-after-free.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
2) CVE-2025-26595: Buffer overflow in XkbVModMaskText()
Introduced in: Prior to X11R6.1
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/11fcda87
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the names of the virtual modifiers to that buffer.
The code however fails to check the bounds of the buffer correctly and
would copy the data regardless of the size, which may lead to a buffer
overflow.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
3) CVE-2025-26596: Heap overflow in XkbWriteKeySyms()
Introduced in: initial version of xc/programs/Xserver/xkb/xkb.c in X11R6
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/80d69f01
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), which may lead to a heap based
buffer overflow.
xorg-server-21.1.16 and xwayland-24.1.6 have been patched to fix this issue.
4) CVE-2025-26597: Buffer overflow in XkbChangeTypesOfKey()
Introduced in: X11R6.1
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/0e4ed949
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
If XkbChangeTypesOfKey() is called with 0 group, it will resize the key
symbols table to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value of groups,
this will cause a buffer overflow because the key actions are of the wrong
size.
5) CVE-2025-26598: Out-of-bounds write in CreatePointerBarrierClient()
Introduced in: xorg-server-1.14.0
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bba9df1a
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The function GetBarrierDevice() searches for the pointer device based on
its device id and returns the matching value, or supposedly NULL if no
match was found.
However the code will return the last element of the list if no matching
device id was found which can lead to out of bounds memory access.
6) CVE-2025-26599: Use of uninitialized pointer in compRedirectWindow()
Introduced in: Xorg 6.8.0.
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/c1ff84behttps://gitlab.freedesktop.org/xorg/xserver/-/commit/b07192a8
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The function compCheckRedirect() may fail if it cannot allocate the backing
pixmap. In that case, compRedirectWindow() will return a BadAlloc error
without the validation of the window tree marked just before, which leaves
the validate data partly initialized, and the use of an uninitialized pointer
later.
7) CVE-2025-26600: Use-after-free in PlayReleasedEvents()
Introduced in: X11R5
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/6e0f332b
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
When a device is removed while still frozen, the events queued for that
device remain while the device itself is freed and replaying the events
will cause a use after free.
8) CVE-2025-26601: Use-after-free in SyncInitTrigger()
Introduced in: X11R6
Fixed in: xorg-server-21.1.16 and xwayland-24.1.6
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/16a1242dhttps://gitlab.freedesktop.org/xorg/xserver/-/commit/f52cea2fhttps://gitlab.freedesktop.org/xorg/xserver/-/commit/8cbc90c8https://gitlab.freedesktop.org/xorg/xserver/-/commit/c2857989
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
When changing an alarm, the values of the change mask are evaluated one
after the other, changing the trigger values as requested and eventually,
SyncInitTrigger() is called.
If one of the changes triggers an error, the function will return early,
not adding the new sync object.
This can be used to cause a use after free when the alarm eventually
triggers.
https://lists.x.org/archives/xorg-announce/2025-February/003584.htmlhttps://lists.x.org/archives/xorg-announce/2025-February/003585.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 65be2c6ac0)
