| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
| 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-06 05:54:40 |
| Message-ID: | aEKCoNIfLxjyKY3r@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Jun 05, 2025 at 04:15:19PM +0200, Jim Jones wrote:
> On 05.06.25 11:47, Jim Jones wrote:
>> 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]
It seems to me that you mean xmlTextWriterEndElement() and not
xmlTextWriterEndAttribute() for the last one.
I've been looking at the rest of the callers (this took some time),
like:
- xmlTextWriterWriteBase64, OK.
- xmlTextWriterWriteBinHex, OK.
- xmlNewStringInputStream, which is intentional in xmlPgEntityLoader()
- xmlAddChildList, where we expect valid input.
- xmlXPathCompiledEval, where valid input is expected.
- xmlXPathNewContext, which is incorrect, could fail an allocation.
- xmlReadMemory, looks OK.
- xmlBufferWriteChar, which could fail on OOM if they need to grow
memory, but let's leave these as they are; I suspect that
xmlBufferCreate() would fail anyway.
>> 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");
Oh. These can return XML_ERR_NO_MEMORY as well, with more error
patterns..
> There is also a further xmlXPathCastNodeToString() call in xml.c at
> xml_xmlnodetoxmltype() - it calls xmlNodeGetContent() and it can return
> NULL.
And it's documented as a routine that returns an allocated string, so
yes, we would miss allocation failures but we should not. I think
that we should move the call of xmlXPathCastNodeToString() inside the
PG_TRY block and rely on the xmlerrcxt given by the caller to log an
error if an allocation fails, marking xmlChar *str as volatile to free
it in the finally block if required.
> The function pgxmlNodeSetToText() also calls xmlXPathCastNodeToString(),
> but apparently xmlBufferAdd() can handle NULL values.[1]
Yeah, the patch I have posted upthread gets that done better.
What do you think?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-xml2-Fix-error-handling-in-corner-cases.patch | text/x-diff | 22.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2025-06-06 06:22:45 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
| Previous Message | Amit Kapila | 2025-06-06 03:43:28 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |