Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org, maralist86(at)mail(dot)ru
Subject: Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL
Date: 2025-06-05 09:47:01
Message-ID: d2410ca0-c0dd-4f63-9e70-3d7a62a5d705@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 05.06.25 11:38, Jim Jones wrote:
>
>
> Hi Michael
>
> Am Do., 5. Juni 2025 um 10:11 Uhr schrieb Michael Paquier
> <michael(at)paquier(dot)xyz <mailto:michael(at)paquier(dot)xyz>>:
>
> On Tue, Jun 03, 2025 at 01:15:33PM -0400, Tom Lane wrote:
> > Thanks for taking this on --- contrib/xml2 is really a mess so far as
> > error handling goes.  Your patch looks like an improvement, although
> > I do have one concern: the routines in xml.c that use an xmlerrcxt
> > seem to check xmlerrcxt->err_occurred pretty frequently, eg xmlStrdup
> > is used like this:
> >
> >             doc->encoding = xmlStrdup((const xmlChar *) "UTF-8");
> >             if (doc->encoding == NULL || xmlerrcxt->err_occurred)
> >                 xml_ereport(xmlerrcxt, ERROR, ERRCODE_OUT_OF_MEMORY,
> >                             "could not allocate XML document");
> >
> > Not sure if that's needed here.
>
> Yes, I was also wondering a bit about this part a couple of days ago
> while looking at the module's code and xml.c.  Looking at cacd42d62cb2
> and its thread (particularly [1]), I think that we need to bite the
> bullet or we are going to miss some error context.
>
> PgXmlErrorContext can remain private in xml.c as we can reuse
> pg_xml_error_occurred() to do the job for out-of-core code. 
>
> > There's more that could be looked at, if you feel like it:
>
> Well, now that you mention these things, I do feel like it while I
> have my hands on this area of the code.
>
> > xml_encode_special_chars seems to need a PG_TRY block to avoid
> > possibly leaking "tt".  I also wonder if it's really not possible
> > for xmlEncodeSpecialChars to fail and return NULL.  (xmltext()
> > doesn't believe that either, but maybe it's wrong too.)
>
> Oh, missed this call.  xmlEncodeSpecialChars() relies on
> xmlEscapeText(), which can return NULL on allocation failures based
> on a check in the upstream code (first argument of the routine is not
> used, only second is).  So xmltext() and xml_encode_special_chars()
> are both wrong; we need a try/catch block for the edge case where
> cstring_to_text_with_len() or cstring_to_text() could fail an
> allocation or we would leak what could have been allocated by libxml.
>
>
> Yeah, xmlEscapeText() does return NULL in some cases[1,2] and
> xmlEncodeSpecialChars() doesn't mind.
>
> Taking a further look at xml.c I am wondering if other functions might
> also need some attention in this regard:
>
> * xmlTextWriterStartElement [3]
> * xmlTextWriterWriteAttribute [4]
> * xmlTextWriterWriteRaw [5]
> * xmlTextWriterEndAttribute [6]
>
> We're assuming they never fail. Perhaps something like this?
>  ...
>  nbytes = xmlTextWriterStartElement(writer, (xmlChar *) xexpr->name);
>  if (nbytes == -1 || xmlerrcxt->err_occurred)
>     xml_ereport(xmlerrcxt, ERROR, ERRCODE_OUT_OF_MEMORY,
>                         "could not allocate xmlTextWriterStartElement");
>
> Best regards, Jim
>
> 1 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlIO.c#L205 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlIO.c#L205>
> 2 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlIO.c#L284 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlIO.c#L284>
> 3 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L967 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L967>
> 4 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1950 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1950>
> 5 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1323 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1323>
> 6 -
> https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1839 <https://github.com/GNOME/libxml2/blob/2b6b3945f2df548b56f2c73c490dda9781f92eb2/xmlwriter.c#L1839
>

Oups .. just replied to Michael.
Sorry!

Jim

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message vignesh C 2025-06-05 10:28:30 Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
Previous Message Hayato Kuroda (Fujitsu) 2025-06-05 06:36:11 RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5