Tuxcare Errata System 0.0.1 5.10 2026-09-18T13:14:14 Community Enterprise Operating System 7 - strip debug symbols from binary files Important TuxCare License Agreement CVE-2026-22796 CVE-2025-69421 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - CVE-2023-5678: fix excessive time in DH check/generation with large Q parameter by adding bounds checks in DH_check_pub_key and DH_generate_key - CVE-2024-0727: fix PKCS12 decoding NULL pointer dereference by adding NULL checks where ContentInfo data can be NULL Moderate TuxCare License Agreement CVE-2024-0727 CVE-2023-5678 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - CVE-2026-28387: fix use-after-free in DANE client code by using X509_free() instead of OPENSSL_free() to properly release reference-counted X509 objects - CVE-2026-28388: fix NULL pointer dereference when processing a delta CRL that has a Delta CRL Indicator but lacks a CRL Number extension - CVE-2026-28389: fix NULL pointer dereference in CMS KeyAgreeRecipientInfo processing when KeyEncryptionAlgorithmIdentifier omits the optional parameter field, by using safe X509_ALGOR_get0() extraction - CVE-2026-28390: fix NULL pointer dereference in CMS KeyTransportRecipientInfo processing when RSA-OAEP SourceFunc parameters are missing, by using safe X509_ALGOR_get0() extraction and OPENSSL_memdup() for label data Important TuxCare License Agreement CVE-2026-28389 CVE-2026-28390 CVE-2026-28388 CVE-2026-28387 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - CVE-2026-45447: fix use-after-free in PKCS7_verify triggered by a crafted PKCS#7 / S-MIME message with an empty digestAlgorithms ASN.1 SET, which made OpenSSL free a caller-owned BIO; free the BIO chain explicitly and stop at the caller-supplied indata BIO Critical TuxCare License Agreement CVE-2026-45447 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - HollowByte: grow the handshake init_buf incrementally as data is received instead of pre-allocating the full peer-declared message size, so a peer that claims a large message but never sends it can no longer strand memory (ELS-2635). Backport of OpenSSL 3.0 commit c5785a5e35 (PR #30794); handled by OpenSSL as a "bug or hardening" fix with no CVE assigned Important TuxCare License Agreement CVE-2025-69419 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - CVE-2026-34180: asn1: avoid content length truncation in asn1_ex_c2i() so a primitive element longer than 2GB can no longer cause a heap buffer over-read - CVE-2026-42766: cms: check that PasswordRecipientInfo.keyDerivationAlgorithm is present before dereferencing it, avoiding a NULL pointer dereference Important TuxCare License Agreement CVE-2026-34180 CVE-2026-42766 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - 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:centos:7 Community Enterprise Operating System 7 - 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:centos:7 Community Enterprise Operating System 7 - CVE-2026-54874: dtls: buffer only a record's own on-wire bytes in dtls1_buffer_record() instead of taking over the whole read buffer, and lower the next-epoch record queue cap from 100 to 16, so a peer sending tiny next-epoch records can no longer pin ~1.7MB of heap per connection Important TuxCare License Agreement CVE-2026-54874 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - 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:centos:7 Community Enterprise Operating System 7 - 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-2019-20838 cpe:/o:centos:centos:7 Community Enterprise Operating System 7 - EA4D-994: Update to 10.48 version - Bundled Unicode data updated 16.0 -> 17.0, which changes what already-written patterns match with no code change and no soname bump: \d gains 10 characters (U+11DE0-U+11DE9), \w gains 4696 and \p{L} gains 4644. Those three are purely additive; the only removal is U+0320, which no longer matches \p{Latin}. Anything dynamically linked against libpcre2-8.so.0 therefore sees the new behaviour on upgrade without being rebuilt. alt-php is not affected: it compiles PHP's bundled PCRE2 (--with-external-pcre is not passed), so its "Requires: alt-pcre2" is vestigial and not evidence of linkage. - Rebased pcre2-10.10-Fix-multilib.patch: upstream reworked the pcre2-config libS block into a case statement that does not cover /opt/alt Critical TuxCare License Agreement CVE-2026-89158 CVE-2026-89157 cpe:/o:centos:centos:7 alt-openssl11 alt-openssl11-devel alt-openssl11-libs alt-libxml2 alt-libxml2-devel alt-libxml2-static alt-pcre alt-pcre-devel alt-pcre2 alt-pcre2-devel alt-pcre2-static alt-pcre2-tools alt-pcre2-utf16 alt-pcre2-utf32 x86_64 1:1.1.1w-3.1.el7 d07bf2a08d50eb66 x86_64 1:1.1.1w-3.2.el7 x86_64 1:1.1.1w-3.3.el7 x86_64 1:1.1.1w-3.4.el7 x86_64 1:1.1.1w-3.5.el7 x86_64 1:1.1.1w-3.6.el7 x86_64 0:2.10.2-6.el7 x86_64 0:2.10.2-7.el7 x86_64 1:1.1.1w-3.8.el7 x86_64 0:2.10.2-9.el7 x86_64 0:8.45-2.el7 x86_64 0:10.48-1.el7