Tuxcare Errata System 0.0.1 5.10 2026-10-23T08:53:27 Community Enterprise Operating System 6 - ELS-2362: release bump to align ICU lines Important TuxCare License Agreement CVE-2025-5222 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2026-86137: out-of-bounds read in the NXT macro in xmlFAParsePosCharGroup - CVE-2026-86138: integer overflow and heap buffer overflow in xmlDictAddQString - CVE-2025-24928: stale-length bounds check inside the xmlSnprintfElements loop (upstream 8c8753ad); this is the stack overflow reachable on 2.10.2 - CVE-2026-86140: unchecked strcat at the entry and exit of xmlSnprintfElements (upstream d1686f91); hardening only on 2.10.2, callers pass an emptied buffer - CVE-2026-86141: NULL pointer dereference in xmlRegNewParserCtxt after a strdup failure - CVE-2026-86142: heap buffer overflow in xmlXPtrEvalXPtrPart from xpointer length saturation - CVE-2026-86143: negative lengths reaching write callbacks in xmlIO - CVE-2026-86144: xmlXIncludeProcess and xmlXIncludeProcessTree do not propagate parseFlags; the include context now inherits every document parse flag (NOENT, RECOVER and HUGE included), not only NONET Critical TuxCare License Agreement CVE-2026-86140 CVE-2026-86138 CVE-2026-86137 CVE-2025-24928 CVE-2026-86144 CVE-2026-86142 CVE-2026-86141 CVE-2026-86143 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2024-56171: use-after-free after xmlSchemaItemListAdd in the XML Schema identity-constraint code (xmlSchemaIDCFillNodeTables, xmlSchemaBubbleIDCNodeTables) - CVE-2026-6653: use-after-free in xmlParseInternalSubset; xmlPushInput() returned -1 for a parameter entity input it had already pushed, so the caller freed an input stream that ctxt->input still pointed at. Reachable through the entity amplification check carried by 2.10.2 for CVE-2021-3541, which this keeps in place. Also guards the xmlSkipBlankChars() loop on XML_PARSER_EOF (upstream e129c1d1), without which the same document spins at 100% CPU once the input is no longer freed Critical TuxCare License Agreement CVE-2024-56171 CVE-2026-6653 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2025-27113: NULL pointer dereference in xmlPatMatch(). An explicit child:: axis step compiled to XML_OP_CHILD, an op that accepts a document node and does not advance the current node, so a pattern such as "/child::name" matched against a document node reached the unguarded node->parent dereference in the XML_OP_ROOT case. Compile child:: to XML_OP_ELEM like the implicit axis (upstream 503f788e), which also makes the DOM matcher agree with the streaming matcher. Upstream fixed only the compiler side; the XML_OP_ROOT dereference is left unguarded here as it is upstream, and no in-tree caller can reach it - CVE-2025-32415: heap out-of-bounds read during XML Schema identity-constraint validation. xmlSchemaIDCFillNodeTables() snapshotted the IDC node-table length before its target loop, but the loop shrinks the table when it moves a duplicate key-sequence to bind->dupls. With the stale length the loop rescans slots past the live end of the table and, once the table is empty, evaluates bind->nodeTable[-1], reading one element before the allocation and driving the node count negative. Use the live bind->nbNodes for both the loop guard and the loop terminator (upstream 384cc7c1, v2.13.8; master twin 487ee1d8, v2.14.2) - CVE-2025-6021: fix integer overflow in xmlBuildQName() (tree.c). The prefix and local-name lengths were held in int and summed in int arithmetic, so a long enough QName made lenn + lenp + 2 wrap negative, which both defeated the buffer-size test -- handing back a caller's 50-byte stack buffer -- and undersized the xmlMallocAtomic() allocation, letting the following memcpy()s and the NUL store write out of bounds. The lengths are now size_t, a negative len is rejected, and the sum is bounded against SIZE_MAX before it is formed. Backport of upstream 17d950ae33c23f87692aa179bacedb6743f3188a. - CVE-2026-11979: multiple stack-based buffer overflows in the xmlcatalog utility's --shell mode. usershell() copied the command token, the argument tail and the argument vector of a line of user input into the fixed-size command[100], arg[400] and argv[20] stack buffers with no bounds check, so a single over-long line corrupted the stack frame. All three copy loops are now bounded and reject over-long input with a diagnostic (upstream cd48d441, first released in v2.15.4). Only the xmlcatalog command-line utility is affected; no library entry point reaches usershell() - xmlcatalog: reject --add/--del invocations that run off the end of argv (upstream b1fea45b). Not a CVE and not part of CVE-2026-11979; carried alongside it because upstream shipped both in the same release and both touch xmlcatalog.c. Without it, "xmlcatalog --add a" reads argv[4] past the end of the argument vector and passes whatever follows - in practice a process environment string - to xmlCatalogAdd() Important TuxCare License Agreement CVE-2026-11979 CVE-2025-32415 CVE-2022-49043 CVE-2025-6021 CVE-2022-40303 CVE-2022-40304 CVE-2024-25062 CVE-2025-27113 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Update to 1.70.0 Important TuxCare License Agreement CVE-2026-27135 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - On el10 only, export LDFLAGS with -Wl,-rpath=%{_libdir} before configure. The el10 toolchain emits neither RPATH nor RUNPATH, so /opt/alt/pcre/usr/bin/pcregrep failed to start with "libpcre.so.1 => not found" even though the package ships that library, and the QA integrity check flagged it. Confirmed with readelf: el6, el7 and el8 all carry RPATH=/opt/alt/pcre/usr/lib64 implicitly from libtool and are left alone. - This is a live defect, not a regression: the already-released alt-pcre-8.42-1.el10 has no RPATH either. The %if rhel >= 10 QA_RPATHS override above only relaxes the rpath checker; it never produced an rpath. Important TuxCare License Agreement CVE-2020-14155 CVE-2019-20838 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Skip the libtoolize/autoreconf step in %prep on el6 only. pcre2 10.48 raised AC_PREREQ to 2.69 and el6 ships an older autoconf, so %prep died with "Autoconf version 2.69 or higher is required" before anything was compiled - which is why el6 was left on 10.34-2 while el7 and el8 moved to 10.48-1. Nothing we patch needs the build system regenerated: pcre2-10.10-Fix-multilib.patch only edits pcre2-config.in, which is in AC_CONFIG_FILES of the shipped configure and is expanded by config.status. Verified that the shipped ./configure alone, with the multilib patch applied, emits pcre2-config with empty libR and libS and no -L@libdir@. Every other platform keeps regenerating exactly as before. Critical TuxCare License Agreement CVE-2026-89158 CVE-2026-89161 CVE-2026-89156 CVE-2026-89160 CVE-2022-1586 CVE-2026-89157 CVE-2022-1587 CVE-2022-41409 CVE-2019-20454 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Fix CVE-2026-58050 (publickey.c attribute-count multiplication overflow), CVE-2026-58051 (publickey.c arbitrary free via uninitialised list entry) - Fix double-free of receive_packet in the publickey subsystem (no CVE, upstream 86301ab5 / #1699) Critical TuxCare License Agreement CVE-2026-7598 CVE-2026-55199 CVE-2026-58050 CVE-2025-15661 CVE-2026-55200 CVE-2026-58051 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Fix CVE-2026-66032 (sftp_open double-free of the status buffer), CVE-2026-66033 (AES-GCM length underflow in _libssh2_cipher_crypt), CVE-2026-66034 (publickey.c comment_len OOB read), CVE-2026-66035 (ETM heap overflow in fullpacket) - Fix length underflow on short chacha20-poly1305 packets (no CVE, GHSA-x4g5-mgfc-cxvv, upstream 15257c08 / #2389) Important TuxCare License Agreement CVE-2026-66033 CVE-2026-66035 CVE-2026-66032 CVE-2026-66034 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2023-28484: NULL pointer dereference in xmlSchemaFixupComplexType(). When a complex type extends a base type by complex content, the effective content model is built by splicing the base type's particle in front of the derived type's; the splice arm walked baseType->subtypes without checking it is non-NULL. A base declared with simpleContent has no particle, so an invalid schema combining the two crashes the parser before the diagnostic that would reject it is emitted. Affects anything parsing an untrusted .xsd, xmllint --schema included. Upstream e4f85f1b (v2.10.4) - CVE-2023-29469: non-deterministic hashing of empty dictionary strings. xmlDictComputeFastKey() guarded only `name == NULL` and so, for a zero-length non-terminated name, read name[0] past the end of the string and returned the constant 0 instead of the per-dictionary seed. Upstream states the impact as "various logic or memory errors, including double frees": an inconsistent key makes the dictionary return the wrong answer for an empty name, and callers that free on it can double free. Taking the seed into account is secondary and, upstream's words, "shouldn't have an impact on security". Guard namelen <= 0 and return the seed. Upstream 547edbf1 (v2.10.4) - CVE-2024-34459: buffer over-read in xmlHTMLPrintFileContext() in xmllint.c. The function backscans from input->cur twice to render the caret line under an offending token; the first scan is bounded by `cur > base`, the second is not, so a parser position at the start of the buffer preceded by newlines walks off the front and keeps reading. CLI only - the function is static to xmllint.c and runs only under --htmlout - and a read, not a write, but we ship xmllint on every platform. Upstream 3ad7f816 (v2.12.7) - CVE-2026-0990: unbounded recursion in catalog URI resolution. xmlCatalogXMLResolve() has carried a MAX_CATAL_DEPTH test and matching depth increment for the public-identifier path for years (catalog.c:1635 and 1641); the URI path had neither, so a delegateURI entry pointing back at its own catalog made xmlCatalogListXMLResolveURI() and xmlCatalogXMLResolveURI() recurse until the stack was exhausted. Add the same depth accounting, and walk a separate cursor so the decrements on the way out apply to the entry that was incremented. The separate MAX_CATAL_DEPTH test at catalog.c:1872, inside xmlCatalogXMLResolveURI(), has no matching increment on that path; it is not claimed to be unreachable in general, since xmlCatalogXMLResolve() has a non-decrementing return at 1830-1831 and parsed catalogs are cached globally. Upstream ac6f0fde (v2.15.2); 1961208e is the identical twin commit Moderate TuxCare License Agreement CVE-2026-0990 CVE-2023-28484 CVE-2024-34459 CVE-2023-29469 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Update to 10.49 - Security-only upstream release: GHSA-r9hj-j2rw-4q3m (HIGH, no CVE id yet) - out-of-bounds write in JIT matching when a growable JIT stack (pcre2_jit_stack_create/pcre2_jit_stack_assign) is used with a pattern that needs an unusually large JIT stack, e.g. very many capturing groups; only src/pcre2_jit_compile.c changes. Library versions 16:1:16 / posix 3:9:0 are revision-only bumps, so libpcre2-8/16/32.so.0 and libpcre2-posix.so.3 keep their sonames and no dependent rebuild is needed. Important TuxCare License Agreement CVE-2026-103111 CVE-2026-86145 cpe:/o:centos:linux:6:GA alt-icu73 alt-libicu73 alt-libicu73-devel alt-libicu73-doc alt-libxml2 alt-libxml2-devel alt-libxml2-static alt-nghttp2 alt-nghttp2-devel alt-pcre alt-pcre-devel alt-pcre2 alt-pcre2-devel alt-pcre2-static alt-pcre2-tools alt-pcre2-utf16 alt-pcre2-utf32 alt-libssh211 alt-libssh211-devel alt-libssh211-docs x86_64 0:73.2-6.el6 d07bf2a08d50eb66 0:73.2-6.el6 x86_64 0:2.10.2-6.el6 x86_64 0:2.10.2-7.el6 x86_64 0:2.10.2-9.el6 x86_64 0:1.70.0-1.el6 x86_64 0:8.45-2.el6 x86_64 0:10.48-2.el6 x86_64 0:1.11.1-6.el6 x86_64 0:1.11.1-7.el6 x86_64 0:2.10.2-10.el6 x86_64 0:10.49-1.el6