* SECURITY UPDATE: NULL pointer dereference in xmlSchemaFixupComplexType - debian/patches/libxml2-2.10.2-CVE-2023-28484.patch: check baseType->subtypes for NULL before splicing the base type's particle in front of the derived type's in xmlSchemaFixupComplexType() in xmlschemas.c; backport of upstream libxml2 e4f85f1b (v2.10.4). A base type declared with simpleContent has no particle, so a schema whose child type extends such a base by complexContent reached that arm with a NULL particle and dereferenced it. The schema is invalid and is rejected a moment later, but the crash happens first, at parse time. Reachable from anything that parses an attacker-supplied .xsd, including xmllint --schema and every caller of xmlSchemaParse(). Upstream's three issue491 test files are not carried: the Schemas target globs test/schemas/*_*.xsd, so they would change the generated test list rather than slot into a case - CVE-2023-28484 * SECURITY UPDATE: non-deterministic hashing of empty dictionary strings - debian/patches/libxml2-2.10.2-CVE-2023-29469.patch: guard namelen <= 0 as well as a NULL name, and return the per-dictionary seed rather than the constant 0, in xmlDictComputeFastKey() in dict.c; backport of upstream libxml2 547edbf1 (v2.10.4). The old guard covered only the NULL case, so a zero-length name that is not NUL-terminated fell through to `value += *name` and read one byte past the end of the string. Upstream states the impact as "various logic or memory errors, including double frees": the inconsistent key makes the dictionary return the wrong answer for an empty name, and callers that free on the strength of it can double free. Taking the seed into account is the secondary half of the change and, upstream's words, "shouldn't have an impact on security". xmlDictComputeBigKey() returns the same constant for an empty name but is left alone, as upstream left it; it has no out-of-bounds read, since it tests namelen <= 0 before touching the data - CVE-2023-29469 * SECURITY UPDATE: buffer over-read in xmllint --htmlout - debian/patches/libxml2-2.10.2-CVE-2024-34459.patch: bound the second backscan in xmlHTMLPrintFileContext() in xmllint.c by `cur > base`, the guard the first backscan already carries; backport of upstream libxml2 3ad7f816 (v2.12.7), also on the 2.11 branch as 8ddc7f13. The loop that recomputes the caret column walked backwards over newlines with no lower bound, so a parser position at the start of the buffer preceded by newlines ran off the front of input->base and kept dereferencing. The function is static to xmllint.c and runs only under --htmlout, so this is the command-line tool rather than the library, and it is a read rather than a write - but xmllint ships in this package on every platform - CVE-2024-34459 * SECURITY UPDATE: unbounded recursion in catalog URI resolution - debian/patches/libxml2-2.10.2-CVE-2026-0990.patch: give xmlCatalogListXMLResolveURI() in catalog.c the MAX_CATAL_DEPTH test and depth accounting that xmlCatalogXMLResolve() has carried for the public-identifier path all along (test at catalog.c:1635, increment at 1641), and walk a separate cursor so the decrements on exit apply to the entry that was incremented; backport of upstream libxml2 ac6f0fde (v2.15.2), whose twin commit 1961208e is byte-identical. A delegateURI entry pointing back at its own catalog, or any cycle among several catalogs, made xmlCatalogListXMLResolveURI() and xmlCatalogXMLResolveURI() recurse without bound until the stack was exhausted and the process died. Reachable wherever catalog resolution runs over catalog files an attacker can influence, including XML_CATALOG_FILES, xmlcatalog and xmllint --catalogs. Note the separate MAX_CATAL_DEPTH test at catalog.c:1872, in xmlCatalogXMLResolveURI(), has no matching increment on that path - it tests the entry handed in at 2132 while both increments are on catal elsewhere. Not claimed to be unreachable in general: xmlCatalogXMLResolve() has a non-decrementing return at 1830-1831 and parsed catalogs are cached globally, so a leaked depth could accumulate; that is upstream's and is not introduced here. Upstream's two test commits are not carried - CVE-2026-0990