The vulnerability lies in the non-linear processing time caused by using strings.ToLower on potentially very long strings for case-insensitive comparisons. The fix involves replacing strings.ToLower(X) == Y with strings.EqualFold(X, Y). I identified the functions where these replacements occurred by analyzing the commit patch 8e66b04771e35c4e4125e8c60334b34e2423effb. These functions are parseDoctype, htmlIntegrationPoint, and the unexported parser state machine functions inBodyIM and inTableIM. While the public Parse, ParseFragment, and ParseFragmentWithOptions functions are the entry points for the malicious input, the actual vulnerable string operations (and thus the exploitable performance issue) were located within these specific internal functions. A profiler would highlight these internal functions or the strings.ToLower calls originating from them during an exploit.