On Tue, 30 Dec 2025, Alan Coopersmith wrote:

On 12/21/25 02:39, Никита Евсиков wrote:
# Compare...
diff /tmp/CentOS_6.10-libXp.so.6.2.0.txt /tmp/Lib_From_RPM_Package- libXp.so.6.2.0.txt
I have strange difference:
85a86
 > U _XEatDataWords
103d103
< U _XIOError
*So, I have two questions to you: how dangerous is this difference for correct running of my old app and why this difference is on same versions libraries?*
_XEatDataWords is a function introduced in the security patches described on
https://www.x.org/wiki/Development/Security/Advisory-2013-05-23/

The core function was added to libX11 and became a part of the libX11 API/ABI
in the libX11 1.6 release. For the libraries like libXp built on top of libX11 their patches were written to check if the function was exported by libX11 - if
so, they link against the libX11 version; if not, they have a private local
fallback copy they call instead, which may call _XIOError.  The fallback was
removed in later releases of those libraries, once libX11 1.6 was out for a
while, as seen in
 https://gitlab.freedesktop.org/xorg/lib/libxp/-/commit/2b57a94231238576
from the libXp 1.0.3 release.

So it appears that of the two libraries you have, one was built to call the
function in libX11 1.6 or later, and one was built with the local fallback to
work with older versions of libX11.  Both should work fine with libX11 1.6 or
later, but only the one which calls _XIOError instead of _XEatDataWords will
work with older versions of libX11 (which have the security bugs from the
above advisory, so shouldn't be used anyways).

Just want to add that the security issue affects libX11 and not Xserver. And since libX11 is userspace it does not lead to privilege escalation.

If the application does not load or use unverified data from the Internet these vulnerabilities should not be remotely exploitable.

So just check with which version of the libraries your application works, if the answer is both, use the more secure one.

best

Vladimir Dergachev


--
       -Alan Coopersmith-                 [email protected]
        Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Reply via email to