Re: BUG #18617: PostgreSQL Server Subprocess Crashes by the XPATH Function Expression with Crafted Arguments

I wrote:
> Based on Nick Wellnhofer's response there, I've experimented with the
> attached WIP patch, and it does seem to prevent the problem as long as
> you have a non-ancient libxml2. This is only WIP because there are
> other xmlXPathCompile calls we'd have to fix.

Here's a fleshed-out patch. I first thought that the XmlTableRoutine
code might need significant surgery, but it turns out not to be a
problem as long as we're willing to assume that XmlTableSetDocument
is called before XmlTableSetRowFilter or XmlTableSetColumnFilter.
Since the sole caller does it like that, this doesn't seem too
onerous. I put in Asserts to check that, though.

> Nick also suggested that we not bother with a separate xmlXPathCompile
> call if we're just going to throw away the compiled expression after
> one use. Perhaps that's good cleanup, not sure. I don't know if
> anyone has serious ambitions of re-using the compiled XPath
> expressions.

I looked at this but realized that it'd cause a user-visible change
in error messages. For instance, in xpath_internal we have

xpathcomp = xmlXPathCtxtCompile(xpathctx, xpath_expr);
if (xpathcomp == NULL || xmlerrcxt->err_occurred)
xml_ereport(xmlerrcxt, ERROR, ERRCODE_INTERNAL_ERROR,
"invalid XPath expression");

xpathobj = xmlXPathCompiledEval(xpathcomp, xpathctx);
if (xpathobj == NULL || xmlerrcxt->err_occurred)
xml_ereport(xmlerrcxt, ERROR, ERRCODE_INTERNAL_ERROR,
"could not create XPath object");

So syntax errors in the XPath expression draw "invalid XPath
expression", but if we merged these into one they'd draw
"could not create XPath object", or at least the same message
as execution-time errors. That seems strictly worse for users,
and even if it were OK it's not the sort of thing I'd like to
change in minor releases. So I think we're best off just doing
the minimum change s/xmlXPathCompile/xmlXPathCtxtCompile/.

I would have liked to include a regression test case showing
that the stack overflow is prevented, but I think we can't
since it would fail with pre-2.9.11 libxml2.

BTW, surely ERRCODE_INTERNAL_ERROR is the wrong errcode to use
here? But that's a matter for a different patch.

regards, tom lane