| Summary: | <dev-libs/libxml2-2.9.4: out-of-bounds read parsing an XML in libxml2 using recover mode | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | gnome |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2016/05/03/8 | ||
| Whiteboard: | A2 [glsa cve] | ||
| Package list: | Runtime testing required: | --- | |
Taking care that even three hours ago they fixed another security issue in master maybe we should way a bit instead of bumping/stabilizing a new version per day :S CVE via http://www.openwall.com/lists/oss-security/2016/05/04/7 Patched via https://git.gnome.org/browse/libxml2/commit/?id=c97750d11bb8b6f3303e7131fe526a61ac65bcfd (first release in v2.9.4). v2.9.4 landed in Gentoo repository via https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/libxml2?id=b68f9389191396b4febff3e7b61f939189364426 @ Security: Please vote! This issue was resolved and addressed in GLSA 201701-37 at https://security.gentoo.org/glsa/201701-37 by GLSA coordinator Thomas Deutschmann (whissi). This issue was resolved and addressed in GLSA 201701-37 at https://security.gentoo.org/glsa/201701-37 by GLSA coordinator Thomas Deutschmann (whissi). |
From ${URL} : We found an out-of-bounds read parsing a specially crafted xml in libxml2 if recover mode is used. It affects all versions. It was discovered before by another guy but for some reason, never reported or fixed. Since upstream is not responding, i think it is a good time to publish some details here. $ xmllint -recover ohizsmaase.xml.-6355798974422201279 ... ==2994== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60040000d5d3 at pc 0x73320a bp 0x7fffffffc1e0 sp 0x7fffffffc1d8 READ of size 1 at 0x60040000d5d3 thread T0 ... 0x60040000d5d3 is located 0 bytes to the right of 3-byte region [0x60040000d5d0,0x60040000d5d3) And backtrace is here: ... #7 0x000000000073320a in xmlBufAttrSerializeTxtContent (buf=0x600c0000a7c0, doc=0x601e0000ef50, attr=0x601000007ea0, string=0x60040000d5d0 <incomplete sequence \341>) at xmlsave.c:2057 #8 0x000000000072af0b in xmlAttrSerializeContent (buf=0x600c0000a820, attr=0x601000007ea0) at xmlsave.c:443 #9 0x000000000072c36c in xmlAttrDumpOutput (ctxt=0x601c0000ca60, cur=0x601000007ea0) at xmlsave.c:780 #10 0x000000000072c3b2 in xmlAttrListDumpOutput (ctxt=0x601c0000ca60, cur=0x601000007ea0) at xmlsave.c:797 #11 0x000000000072dc22 in xmlNodeDumpOutputInternal (ctxt=0x601c0000ca60, cur=0x60180000b440) at xmlsave.c:1055 #12 0x000000000072ef8a in xmlDocContentDumpOutput (ctxt=0x601c0000ca60, cur=0x601e0000ef50) at xmlsave.c:1234 #13 0x000000000073246c in xmlSaveDoc (ctxt=0x601c0000ca60, doc=0x601e0000ef50) at xmlsave.c:1936 #14 0x000000000040a238 in parseAndPrintFile (filename=0x7fffffffe759 "ohizsmaase.xml.-6355798974422201279", rectxt=0x0) at xmllint.c:2689 #15 0x000000000040fe5e in main (argc=3, argv=0x7fffffffe4a8) at xmllint.c:3739 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.