- 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