Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org, maralist86@mail.ru
Date: 2025-06-06T05:54:40Z
Lists: pgsql-bugs
Attachments
- v3-0001-xml2-Fix-error-handling-in-corner-cases.patch (text/x-diff) patch v3-0001
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
xml2: Fix failure with xslt_process() under -fsanitize=undefined
- 70f7c5badcc0 14.23 landed
- 0b0041b942f7 15.18 landed
- 5f46c617e95f 16.14 landed
- 63aa4342da23 17.10 landed
- e33a4fda0027 18.4 landed
- 7d64419f8073 19 (unreleased) landed
-
Fix misuse of "volatile" in xml.c
- 6307b096e259 19 (unreleased) landed
-
xml2: Improve error handling of libxml2 calls
- 732061150b00 19 (unreleased) landed
-
Improve error handling of libxml2 calls in xml.c
- 2e947217474c 19 (unreleased) landed