While investigating T85848, realized that yes, we are vulnerable to this.

In the most basic attack where all of the entities are in the text of a single element, it results in a String size overflow when the size gets over 2GB. If the entities are grouped into elements so no string is longer than 2GB, then zend eventually bails with zend_mm_heap corrupted.

The fix for T85848 should fix this (require resource limits before doing xml parsing). I'm not sure if that's more or less ugly than wordpress removing the DOCTYPE section before processing.

Demo of standard quadratic blowup, divided up so no string exceeds 2GB:

In T71210#1035288, @csteipp wrote:

I'm not sure if that's more or less ugly than wordpress removing the DOCTYPE section before processing.

For reference, https://core.trac.wordpress.org/changeset/29404.

We could probably get away with that when we're just trying to figure out if the file is xml (MimeMagic's use of XmlTypeCheck), but we obviously have to leave entity expansion in for SVG filtering.

XMLReader sanely stops parsing the xml when the expansion gets too big (around 15KB of entities for attributes, and somewhere between 50-100KB of entities in the body). xml_parse (under zend) stops parsing after about 10KB of entities, but when the entities are in the xml body, it keeps processing the expansion until it finishes. When the xml body data is added to a string in php, the string can either cause php to hit the memory limit, overflow the string length limit, or if memory_limit isn't set below the available memory zend quits and complains about heap corruption.

With the patch for T88310, svg parsing uses XMLReader so it's safe. XMP parsing is vulnerable without the patch from T85848. We can either backport the XMP patch to address this, or ensure memory_limit is set before parsing XMP blocks. Backporting the full XMP patch is probably easiest.