Xorg vulnerabilities, again because AI work

[nick65go]

Another Dozen (=12) Vulnerabilities Found In The X.Org Server & XWayland
https://www.phoronix.com/news/X.Org-12-New-Issues-2026
These issues are present in versions prior to the new xorg-server-21.1.25 and xwayland-24.1.14.

[Franio]

Ok but as long as those security bugs are not remote execute bugs there is little to nothing to worry about. Even if some of them are from remote vector does it mean that standard TCL installation with Xorg-7.7.tcz installed from repo will be exploitable? See, many features are disabled in order to lower depends for packages and in order to save space, memory etc. And I think Xorg doen't listen on 0.0.0.0 by default.

But keep an eye on tools that listens on network interfaces. There was some bugs in busybox dhcp client. Busybox is core of every tcl and other embedded tiny linux distros.

The other thing is there is no LTS (older and mature) kernel to select from and I understand supporting another kernel may cost more but I think LTS are just more secure and more stable (don't comes with regressions). I am going to say the first thing to protect is kernel because Linux is monolithic and single bug in kernel leads to code execution in kernel mode. There are some apis for user space drivers (EL0 drivers in arm) but make rare use of. I suggest 'git clone'ing linux repo, select lts branch, make olddefconfig, and then build kernel Image.gz and you can compile with modules built-in or without. And if single new release comes to world you just do 'git pull' and make recompiles only files that were modified or files that depend on files that were modified by recent release. By making dirty builds you save time and stay secure.

[nick65go]

https://www.phoronix.com/news/17-Vulnerabilities-Xorg-Libs17 
More Security Vulnerabilities Made Public For X.Org Libraries 
Updated versions include libX11 1.8.14, libXi 1.8.4, libXpm 3.5.20, libXrender 0.9.13, and libXtst 1.2.6.
I do not like / dislike too much Wayland, but Xorg /x11 is systematically ... to say it polite ... not anymore the best for daily security or speed IF you are not constrained (at end of the year 2026) by resources (RAM, CPU, HDD).

... What happened is every major distro switched over to wayland by default: Ubuntu. Debian. RHEL. SUSE. Fedora. Even Arch heavily defaults to wayland these days. Any remaining X11-based development is either life support for Xorg while the last stragglers migrate off, or small forks trying desperately to keep it alive without understanding the burden they've signed up for.

[CNK]

I second Franio. These bug descriptions are all about things "a malicious X server" could do. Are you going to be using "a malicious X server"? Probably not. If using Wayland is an option for you then definately not because it doesn't allow you to run a separate display server, eg. on another computer to the one running the client/application, anyway.

In practice there's rarely ever going to be a reason to trust the X server or client (program that's running, possibly using these libraries) any differently anyway, since they'll both have come from the distro's package repo. So if a malicious X server in installed which can hack into the program you're using, it's just as likely that the program you're using is malicious and will just be naughty on its own.

But anyway Xorg is hardly the only software with lots security alerts, check out all the vulnerabilities Firefox reports.

Switch to Wayland yourself if you want to. But as an argument for others to do so, these security bugs are irrelevent. I for one value the extra capabilities and software-compatibility of X and will definitely be sticking with it. Tiny Core's TinyX servers are also very resource efficient already.

[nick65go]

Hi CNK, thanks for your feedback-option.
1- "these security bugs are irrelevant" - I respect your opinion, but for me securities (for ANY program, Firefox included) are important.

2- "Tiny Core's TinyX servers are also very resource efficient already." - correct. Unfortunately my hardware is fully 3D capable, but TinyX is not. So for a daily distro (not a rescue / nomad OS) I prefer a fully accelerated graphics. (X11 or Wayland).

3- Xorg/apps: "since they'll both have come from the distro's package repo" - correct, Nothing is wrong with TC repositories, as they were designed. But when I have an opportunity, I prefer signed-repositories with signed-packages. It is all about trust in the kindness of our world. Unfortunately there are some (long term) frictions between America / Europe / Russia / China.

4. "I for one value the extra capabilities and software-compatibility" - OK!!. So for me, I did not find any SIGNIFICANT smaller + secure browser than Firefox. Neither for (Excel) XLSX compatibility smaller than LibreOffice. Or better MPV player with video acceleration. So if YOU do not need Firefox + LibreOffice + MVP, than ..lucky you. But if someone needs things like those then the "insecure" Xorg/X11 3D is not significant smaller than any Wayland "display/compositor" server. YMMV.

5. I "prepare" myself for Labwc - as Wayland window-stacking compositor. Because anyway Xorg-3D-accerelation will drag enormously resources (LLVM, firmware, vulkan drivers, whatever). So at that point a "tiny core" versus a "fat body" matters less.

[Juanito]

As an aside, you don’t necessarily need llvm for 3d acceleration as long as you drop software acceleration and have the right graphics hardware.

[nick65go]

As an aside, you don’t necessarily need llvm for 3d acceleration as long as you drop software acceleration and have the right graphics hardware.

Wow, nice info. Could you please expand/explain to me? Can be done without recompile packages, I mean just few settings in environment? Usually LLWM*.so* are a dependency of some previously loaded *.so. Thanks!

[Juanito]

Unfortunately you’d need to recompile the x86 and x86_64 versions of mesa.

The aarch64 version of mesa doesn’t need llvm.

As I recall, at least some amd and all nvidia graphics hardware drivers need llvm. I believe all intel hardware drivers don’t need llvm.