Use after free in Blink XSLT in Google Chrome prior to 91.0.4472.164 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
A vulnerability in function xsltStylePreCompute" in preproc.c was found, the cause of which is a type confusion leading to DoS.
As reported in https://bugzilla.redhat.com/showbug.cgi?id=1257058 :
""" Through analysis we get to know that parent->ns->href in line 2250 of preproc.c is an invalid value with our poc. The whole process is as follow: 1> The main function in xsltproc.c will call xmlReadFile to read a .xml file. xmlReadFile will return a xmlDocPtr which points to the xmlDoc. When we print xmlDocPtr->children->parent->ns, its value is 0xffffffff. Obviously, this value is not a correct one. 2> Later in xsltStylePreCompute of preproc.c, the function will see whether current element is 'attribute', if yes,if inst->parent!=NULL and parent->ns!=NULL, then it will call xmlStrEqual, the first parameter is a ptr but its value is 0xffffffff! 3> We went further into libxml and see why this happened.The result is : in SAX2.c +2293 of libxml, we found that the first parameter "ctxt->myDoc" is a xmlDocPtr, but it will be teated as a xmlNodePtr. Obviously, xmlDoc and xmlNode have different structure. This is why "xmlDocPtr->children->parent->ns" get a invalid value(0xffffffff), this value comes from xmlDoc->compression. """
libxslt, as used in Google Chrome before 17.0.963.46, allows remote attackers to cause a denial of service (out-of-bounds read) via unspecified vectors.
Chris Evans discovered a heap address leak in XSLT The bug is in the generate-id() XPath function, and is sometimes used in XSL transforms. This is a low severity information leak, that does not corrupt anything, However it can be paired with other bugs and can be perhaps used as an exploit aid against ASLR.
References: http://scarybeastsecurity.blogspot.com/2011/03/multi-browser-heap-address-leak-in-xslt.html http://git.gnome.org/browse/libxslt/commit/?id=ecb6bcb8d1b7e44842edde3929f412d46b40c89f
This has been assigned CVE-2011-1202.
libxslt before 1.1.28 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via an (1) empty match attribute in a XSL key to the xsltAddKey function in keys.c or (2) uninitialized variable to the xsltDocumentFunction function in functions.c.
libxslt in Apple iOS before 9.3.3, OS X before 10.11.6, iTunes before 12.4.2 on Windows, iCloud before 5.2.1 on Windows, tvOS before 9.2.2, and watchOS before 2.2.2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors, a different vulnerability than CVE-2016-4608, CVE-2016-4609, CVE-2016-4610, and CVE-2016-4612.
libxslt in Apple iOS before 9.3.3, OS X before 10.11.6, iTunes before 12.4.2 on Windows, iCloud before 5.2.1 on Windows, tvOS before 9.2.2, and watchOS before 2.2.2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors, a different vulnerability than CVE-2016-4607, CVE-2016-4609, CVE-2016-4610, and CVE-2016-4612.
libxslt in Apple iOS before 9.3.3, OS X before 10.11.6, iTunes before 12.4.2 on Windows, iCloud before 5.2.1 on Windows, tvOS before 9.2.2, and watchOS before 2.2.2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors, a different vulnerability than CVE-2016-4607, CVE-2016-4608, CVE-2016-4609, and CVE-2016-4612.
libxslt in Apple iOS before 9.3.3, OS X before 10.11.6, iTunes before 12.4.2 on Windows, iCloud before 5.2.1 on Windows, tvOS before 9.2.2, and watchOS before 2.2.2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors, a different vulnerability than CVE-2016-4607, CVE-2016-4608, CVE-2016-4610, and CVE-2016-4612.
An integer overflow flaw was found in the libxslt component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=583171
External References:
http://googlechromereleases.blogspot.com/2016/05/stable-channel-update25.html
An out-of-bounds access flaw was found in the libxslt component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=583156
External References:
http://googlechromereleases.blogspot.com/2016/05/stable-channel-update25.html
Type confusion in xsltNumberFormatGetMultipleLevel prior to libxslt 1.1.33 could allow attackers to potentially exploit heap corruption via crafted XML data.
libxslt through 1.1.33 allows bypass of a protection mechanism because callers of xsltCheckRead and xsltCheckWrite permit access even upon receiving a -1 error code. xsltCheckRead can return -1 for a crafted URL that is not actually invalid and is subsequently loaded.
Upstream commit: https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6
Chris Evans discovered a heap address leak in XSLT The bug is in the generate-id() XPath function, and is sometimes used in XSL transforms. This is a low severity information leak, that does not corrupt anything, However it can be paired with other bugs and can be perhaps used as an exploit aid against ASLR.
References: http://scarybeastsecurity.blogspot.com/2011/03/multi-browser-heap-address-leak-in-xslt.html http://git.gnome.org/browse/libxslt/commit/?id=ecb6bcb8d1b7e44842edde3929f412d46b40c89f
This has been assigned CVE-2011-1202.