| 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
| 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 |