Bugzilla – Bug 1199892
VUL-1: CVE-2022-29358: epub2txt2: integer overflow via the function bug in _parse_special_tag at sxmlc.c
Last modified: 2022-05-26 02:52:55 UTC
CVE-2022-29358 epub2txt2 v2.04 was discovered to contain an integer overflow via the function bug in _parse_special_tag at sxmlc.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted XML file. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-29358 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29358 https://github.com/kevinboone/epub2txt2/issues/22
Affected: - openSUSE:Factory/epub2txt2 2.04
Seems the author of epub2txt2 said """ I'm not sure what to do about this. The failure occurs because epub2txt is fed with gibberish XML. So it crashes. It crashes in a clean and safe way because there's an immediate segfault. Sure, it would be nicer for the user to get a more helpful error message, but I suspect there's a gazillion ways you could formulate a broken EPUB that would crash the utility. The EPUB supplied here crashes the Calibre EPUB viewer as well, although you get a Python stack back-trace rather than segfault. But it still fails. I use a lightweight XML parser to keep the size of epub2txt to a minimum, so it can run on embedded systems. Probably I'd get a nicer mode of failure if I used a full-fat XML parser. But -- and this is the main point I'm trying to make -- it will still fail. So I'm unsure what merit there is to fixing this bug. I'm not denying it's a bug, but fixing it won't really make epub2txt a better utility. It still won't be able to process a corrupt EPUB. If epub2txt crashes with any well-formed EPUB, that can be displayed using other viewers, that's something I'd want to fix. This kind of thing, though, I'm not sure. Comments welcome. """ Source: https://github.com/kevinboone/epub2txt2/issues/22#issuecomment-1099279662