| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| xml2-config-fix.patch | display dynamic linking information with --libs, not static Don't bother about keeping support for the static variant, it's not needed in debian directly. |
Mattia Rizzolo <mattia@debian.org> | no | debian | 2020-02-23 | |
| Fix-memory-leak-in-xmlSchemaValidateStream.patch | Fix memory leak in xmlSchemaValidateStream When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun alloc a new schema for ctxt->schema and set vctxt->xsiAssemble to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize vctxt->xsiAssemble to 0 again which cause the alloced schema can not be freed anymore. Found with libFuzzer. |
Zhipeng Xie <xiezhipeng1@huawei.com> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a | 2019-08-20 |
| Fix-infinite-loop-in-xmlStringLenDecodeEntities.patch | Fix infinite loop in xmlStringLenDecodeEntities When ctxt->instate == XML_PARSER_EOF,xmlParseStringEntityRef return NULL which cause a infinite loop in xmlStringLenDecodeEntities Found with libFuzzer. |
Zhipeng Xie <xiezhipeng1@huawei.com> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c8907645d2e155f0d89d4d9895ac5112b5 | 2019-12-12 |
| Fix-freeing-of-nested-documents.patch | [PATCH] Fix freeing of nested documents Apparently, some libxslt RVTs can contain nested document nodes, see issue #132. I'm not sure how this happens exactly but it can cause a segfault in xmlFreeNodeList after the changes in commit 0762c9b6. Make sure not to touch the (nonexistent) `content` member of xmlDocs. |
Nick Wellnhofer <wellnhofer@aevum.de> | no | 2019-12-06 | ||
| python3-unicode-errors.patch | https://gitlab.gnome.org/GNOME/libxml2/issues/64 =================================================================== |
no | https://src.fedoraproject.org/rpms/libxml2/blob/master/f/libxml2-2.9.8-python3-unicode-errors.patch | |||
| parenthesize-type-checks.patch | [PATCH] Parenthesize Py<type>_Check() in ifs In C, if expressions should be parenthesized. PyLong_Check, PyUnicode_Check etc. happened to expand to a parenthesized expression before, but that's not API to rely on. Since Python 3.9.0a4 it needs to be parenthesized explicitly. Fixes https://gitlab.gnome.org/GNOME/libxml2/issues/149 |
=?UTF-8?q?Miro=20Hron=C4=8Dok?= <miro@hroncok.cz> | no | 2020-02-28 | ||
| Fix-out-of-bounds-read-with-xmllint-htmlout.patch | Fix out-of-bounds read with 'xmllint --htmlout' Make sure that truncated UTF-8 sequences don't cause an out-of-bounds array access. Thanks to @SuhwanSong and the Agency for Defense Development (ADD) for the report. Fixes #178. |
Nick Wellnhofer <wellnhofer@aevum.de> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2 | 2020-08-07 |
| Fix-use-after-free-with-xmllint-html-push.patch | Fix use-after-free with `xmllint --html --push` Call htmlCtxtUseOptions to make sure that names aren't stored in dictionaries. Note that this issue only affects xmllint using the HTML push parser. Fixes #230. |
Nick Wellnhofer <wellnhofer@aevum.de> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/1358d157d0bd83be1dfe356a69213df9fac0b539 | 2021-04-21 |
| Validate-UTF8-in-xmlEncodeEntities.patch | Validate UTF8 in xmlEncodeEntities Code is currently assuming UTF-8 without validating. Truncated UTF-8 input can cause out-of-bounds array access. Adds further checks to partial fix in 50f06b3e. Fixes #178 |
Joel Hockey <joel.hockey@gmail.com> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2 | 2020-08-16 |
| Fix-user-after-free-with-xmllint-xinclude-dropdtd.patch | Fix user-after-free with `xmllint --xinclude --dropdtd` The --dropdtd option can leave dangling pointers in entity reference nodes. Make sure to skip these nodes when processing XIncludes. This also avoids scanning entity declarations and even modifying them inadvertently during XInclude processing. Move from a block list to an allow list approach to avoid descending into other node types that can't contain elements. Fixes #237. |
Nick Wellnhofer <wellnhofer@aevum.de> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/1098c30a040e72a4654968547f415be4e4c40fe7 | 2021-04-22 |
| Propagate-error-in-xmlParseElementChildrenContentDec.patch | Propagate error in xmlParseElementChildrenContentDeclPriv Check return value of recursive calls to xmlParseElementChildrenContentDeclPriv and return immediately in case of errors. Otherwise, struct xmlElementContent could contain unexpected null pointers, leading to a null deref when post-validating documents which aren't well-formed and parsed in recovery mode. Fixes #243. |
Nick Wellnhofer <wellnhofer@aevum.de> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/babe75030c7f64a37826bb3342317134568bef61 | 2021-05-01 |
| Patch-for-security-issue-CVE-2021-3541.patch | Patch for security issue CVE-2021-3541 This is relapted to parameter entities expansion and following the line of the billion laugh attack. Somehow in that path the counting of parameters was missed and the normal algorithm based on entities "density" was useless. |
Daniel Veillard <veillard@redhat.com> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/8598060bacada41a0eb09d95c97744ff4e428f8e | 2021-05-13 |
| CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch | [CVE-2022-23308] Use-after-free of ID and IDREF attributes If a document is parsed with XML_PARSE_DTDVALID and without XML_PARSE_NOENT, the value of ID attributes has to be normalized after potentially expanding entities in xmlRemoveID. Otherwise, later calls to xmlGetID can return a pointer to previously freed memory. ID attributes which are empty or contain only whitespace after entity expansion are affected in a similar way. This is fixed by not storing such attributes in the ID table. The test to detect streaming mode when validating against a DTD was broken. In connection with the defects above, this could result in a use-after-free when using the xmlReader interface with validation. Fix detection of streaming mode to avoid similar issues. (This changes the expected result of a test case. But as far as I can tell, using the XML reader with XIncludes referencing the root document never worked properly, anyway.) All of these issues can result in denial of service. Using xmlReader with validation could result in disclosure of memory via the error channel, typically stderr. The security impact of xmlGetID returning a pointer to freed memory depends on the application. The typical use case of calling xmlGetID on an unmodified document is not affected. |
Nick Wellnhofer <wellnhofer@aevum.de> | yes | debian upstream | https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12a858989b14eed4e84e453059cd3ba340e | 2022-02-08 |
| Fix-integer-overflow-in-xmlBufferResize.patch | Fix integer overflow in xmlBufferResize Found by OSS-Fuzz. |
Nick Wellnhofer <wellnhofer@aevum.de> | no | https://gitlab.gnome.org/GNOME/libxml2/-/commit/b07251215ef48c70c6e56f7351406c47cfca4d5b | 2020-01-10 | |
| CVE-2022-29824-Fix-integer-overflows-in-xmlBuf-and-x.patch | [CVE-2022-29824] Fix integer overflows in xmlBuf and xmlBuffer In several places, the code handling string buffers didn't check for integer overflow or used wrong types for buffer sizes. This could result in out-of-bounds writes or other memory errors when working on large, multi-gigabyte buffers. Thanks to Felix Wilhelm for the report. |
Nick Wellnhofer <wellnhofer@aevum.de> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/-/commit/2554a2408e09f13652049e5ffb0d26196b02ebab | 2022-03-08 |
| CVE-2022-40303-Fix-integer-overflows-with-XML_PARSE_.patch | [CVE-2022-40303] Fix integer overflows with XML_PARSE_HUGE Also impose size limits when XML_PARSE_HUGE is set. Limit size of names to XML_MAX_TEXT_LENGTH (10 million bytes) and other content to XML_MAX_HUGE_LENGTH (1 billion bytes). Move some the length checks to the end of the respective loop to make them strict. xmlParseEntityValue didn't have a length limitation at all. But without XML_PARSE_HUGE, this should eventually trigger an error in xmlGROW. Thanks to Maddie Stone working with Google Project Zero for the report! |
Nick Wellnhofer <wellnhofer@aevum.de> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/-/commit/c846986356fc149915a74972bf198abc266bc2c0 | 2022-08-25 |
| CVE-2022-40304-Fix-dict-corruption-caused-by-entity-.patch | [CVE-2022-40304] Fix dict corruption caused by entity reference cycles When an entity reference cycle is detected, the entity content is cleared by setting its first byte to zero. But the entity content might be allocated from a dict. In this case, the dict entry becomes corrupted leading to all kinds of logic errors, including memory errors like double-frees. Stop storing entity content, orig, ExternalID and SystemID in a dict. These values are unlikely to occur multiple times in a document, so they shouldn't have been stored in a dict in the first place. Thanks to Ned Williamson and Nathan Wachholz working with Google Project Zero for the report! |
Nick Wellnhofer <wellnhofer@aevum.de> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/-/commit/1b41ec4e9433b05bb0376be4725804c54ef1d80b | 2022-08-31 |
| schemas-Fix-null-pointer-deref-in-xmlSchemaCheckCOSS.patch | schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK Found by OSS-Fuzz. |
Nick Wellnhofer <wellnhofer@aevum.de> | no | https://gitlab.gnome.org/GNOME/libxml2/-/commit/4c6922f763ad958c48ff66f82823ae21f2e92ee6 | 2022-09-13 | |
| CVE-2023-28484-Fix-null-deref-in-xmlSchemaFixupCompl.patch | [CVE-2023-28484] Fix null deref in xmlSchemaFixupComplexType Fix a null pointer dereference when parsing (invalid) XML schemas. Thanks to Robby Simpson for the report! Fixes #491. |
Nick Wellnhofer <wellnhofer@aevum.de> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/-/commit/647e072ea0a2f12687fa05c172f4c4713fdb0c4f | 2023-04-07 |
| CVE-2023-29469-Hashing-of-empty-dict-strings-isn-t-d.patch | [CVE-2023-29469] Hashing of empty dict strings isn't deterministic When hashing empty strings which aren't null-terminated, xmlDictComputeFastKey could produce inconsistent results. This could lead to various logic or memory errors, including double frees. For consistency the seed is also taken into account, but this shouldn't have an impact on security. Found by OSS-Fuzz. Fixes #510. [Salvatore Bonaccorso: Backport to 2.9.10 for context changes without 3c8a3e9922cb ("Use random seed in xmlDictComputeFastKey") in 2.9.11.] |
Nick Wellnhofer <wellnhofer@aevum.de> | no | debian | https://gitlab.gnome.org/GNOME/libxml2/-/commit/09a2dd453007f9c7205274623acdd73747c22d64 | 2023-04-07 |