[PATCH] contrib/xml2: backend crash in xpath_nodeset() on the namespace axis
Hi,
In the xml2 extension, xpath_nodeset() crashes the backend on an XPath
that selects namespace-axis nodes. xpath_nodeset() is executable by
PUBLIC by default, so any role that can run SQL can crash the server
with one query:
CREATE EXTENSION xml2;
SELECT xpath_nodeset('<root
xmlns:foo="http://example.com/foo"><child/></root>',
'//namespace::*');
Cause: pgxmlNodeSetToText() (contrib/xml2/xpath.c:197) calls
xmlNodeDump(buf, nodeset->nodeTab[i]->doc, nodeset->nodeTab[i], 1,
0);
with no node-type check. Namespace-axis results are XML_NAMESPACE_DECL
nodes (xmlNs structs cast to xmlNodePtr), so reading the node's ->doc
field runs past the smaller xmlNs allocation, and the bogus value is
then dereferenced as the document by xmlNodeDump(). xpath_list() and
xpath_table() already avoid this via xmlXPathCastNodeToString(); only
the xmlNodeDump() path is exposed.
Reproduced on master; the same unguarded xmlNodeDump() call in
pgxmlNodeSetToText() is present on every supported back-branch (REL_18
through REL_14).
Patch attached: render XML_NAMESPACE_DECL nodes with
xmlXPathCastNodeToString() like xpath_table() does. The repro then
returns the namespace text, ordinary node-set output is unchanged, and
the xml2 regression test passes.
--
Andrey Chernyy
On Thu, Jun 11, 2026 at 03:14:36AM +0300, Andrey Chernyy wrote:
Reproduced on master; the same unguarded xmlNodeDump() call in
pgxmlNodeSetToText() is present on every supported back-branch (REL_18
through REL_14).Patch attached: render XML_NAMESPACE_DECL nodes with
xmlXPathCastNodeToString() like xpath_table() does. The repro then
returns the namespace text, ordinary node-set output is unchanged, and
the xml2 regression test passes.
Thanks for the report, that looks about right to fix the way you are
doing in xml2. Some tests and we should be good.
Hmm. We have a second caller of xmlNodeDump() in the core backend
code in adt/xml.c, leading to a confusing error if I try to use a
namespace:
=# select xpath('//namespace::*', '<root xmlns:foo="http://example.com"/>'::xml);
ERROR: 53200: could not copy node
CONTEXT: SQL function "xpath" statement 1
LOCATION: xml_ereport, xml.c:2082
It looks to me that we should fallback to xmlXPathCastNodeToString()
when dealing with a NAMESPACE_DECL. The attached patch leads me to
the following result, that looks much better:
=# select xpath('//namespace::*', '<root xmlns:foo="http://example.com"/>'::xml);
xpath
-----------------------------------------------------------
{http://www.w3.org/XML/1998/namespace,http://example.com}
(1 row)
What do you think? That also deserves a backpatch to me, even if it
is less worse than the xml2 crash you have reported.
I have grouped this fix with your patch in the attached. Both still
need some tests. Each fix deserves its own commit, that's just a
quick FYI version.
--
Michael
Attachments:
v2-0001-xml2-don-t-crash-on-namespace-nodes-in-xpath_node.patchtext/plain; charset=us-asciiDownload+17-6
On Thu, 11 Jun 2026 10:48:30 +0900
Michael Paquier <michael@paquier.xyz> wrote:
What do you think? That also deserves a backpatch to me, even if it
is less worse than the xml2 crash you have reported.I have grouped this fix with your patch in the attached. Both still
need some tests. Each fix deserves its own commit, that's just a
quick FYI version.
Thanks Michael, and thanks for adding the tests and back-patching! The
grouped patch looks good to me - applying the same XML_NAMESPACE_DECL
fallback to xmlXPathCastNodeToString() in core xml.c makes sense too. I
had a regression test in progress, but glad it's already covered.
--
Andrey Chernyy
On Fri, Jun 12, 2026 at 01:59:06AM +0300, Andrey Chernyy wrote:
Thanks Michael, and thanks for adding the tests and back-patching! The
grouped patch looks good to me - applying the same XML_NAMESPACE_DECL
fallback to xmlXPathCastNodeToString() in core xml.c makes sense too. I
had a regression test in progress, but glad it's already covered.
Both issues are now fixed and backpatched, as of 8bf257aebac1 and
9d33a5a804db.
--
Michael