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

PG Bug reporting form <noreply@postgresql.org> writes:
> SELECT XPATH(REPEAT('(', 100000), '<root/>');

> GDB Backtrace (It seems to be a stack overflow):

Yeah, with debug symbols it looks like

(gdb) bt
#0  0x00007f14666a177d in xmlXPathCompMultiplicativeExpr (ctxt=0x2b79ab0) at ../xpath.c:10864
#1  0x00007f14666a1ee4 in xmlXPathCompAdditiveExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#2  xmlXPathCompRelationalExpr (ctxt=0x2b79ab0) at ../xpath.c:10943
#3  xmlXPathCompEqualityExpr (ctxt=0x2b79ab0) at ../xpath.c:10985
#4  xmlXPathCompAndExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#5  xmlXPathCompileExpr (ctxt=0x2b79ab0, sort=1) at ../xpath.c:11042
#6  0x00007f14666a071a in xmlXPathCompPrimaryExpr (ctxt=<optimized out>) at ../xpath.c:10528
#7  xmlXPathCompFilterExpr (ctxt=<optimized out>) at ../xpath.c:10562
#8  xmlXPathCompPathExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10769
#9  0x00007f14666a15b6 in xmlXPathCompUnionExpr (ctxt=0x2b79ab0) at ../xpath.c:10839
#10 xmlXPathCompUnaryExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10839
#11 0x00007f14666a1782 in xmlXPathCompMultiplicativeExpr (ctxt=0x2b79ab0) at ../xpath.c:10864
#12 0x00007f14666a1ee4 in xmlXPathCompAdditiveExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#13 xmlXPathCompRelationalExpr (ctxt=0x2b79ab0) at ../xpath.c:10943
#14 xmlXPathCompEqualityExpr (ctxt=0x2b79ab0) at ../xpath.c:10985
#15 xmlXPathCompAndExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#16 xmlXPathCompileExpr (ctxt=0x2b79ab0, sort=1) at ../xpath.c:11042
#17 0x00007f14666a071a in xmlXPathCompPrimaryExpr (ctxt=<optimized out>) at ../xpath.c:10528
#18 xmlXPathCompFilterExpr (ctxt=<optimized out>) at ../xpath.c:10562
#19 xmlXPathCompPathExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10769
#20 0x00007f14666a15b6 in xmlXPathCompUnionExpr (ctxt=0x2b79ab0) at ../xpath.c:10839
#21 xmlXPathCompUnaryExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10839
#22 0x00007f14666a1782 in xmlXPathCompMultiplicativeExpr (ctxt=0x2b79ab0) at ../xpath.c:10864
#23 0x00007f14666a1ee4 in xmlXPathCompAdditiveExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#24 xmlXPathCompRelationalExpr (ctxt=0x2b79ab0) at ../xpath.c:10943
#25 xmlXPathCompEqualityExpr (ctxt=0x2b79ab0) at ../xpath.c:10985
#26 xmlXPathCompAndExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
#27 xmlXPathCompileExpr (ctxt=0x2b79ab0, sort=1) at ../xpath.c:11042
#28 0x00007f14666a071a in xmlXPathCompPrimaryExpr (ctxt=<optimized out>) at ../xpath.c:10528
#29 xmlXPathCompFilterExpr (ctxt=<optimized out>) at ../xpath.c:10562
#30 xmlXPathCompPathExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10769
#31 0x00007f14666a15b6 in xmlXPathCompUnionExpr (ctxt=0x2b79ab0) at ../xpath.c:10839
#32 xmlXPathCompUnaryExpr (ctxt=ctxt@entry=0x2b79ab0) at ../xpath.c:10839
#33 0x00007f14666a1782 in xmlXPathCompMultiplicativeExpr (ctxt=0x2b79ab0) at ../xpath.c:10864
#34 0x00007f14666a1ee4 in xmlXPathCompAdditiveExpr (ctxt=0x2b79ab0) at ../xpath.c:11016
... etc etc...

Fundamentally, this is a libxml2 bug that we can't do much about.
There are various hard-wired limits on document complexity in libxml2,
but they don't seem to be trapping this particular case, and we have
no ability to adjust them anyway.  You might try filing a bug with
the libxml2 authors.

            regards, tom lane