From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Erik Wienhold <ewie(at)ewie(dot)name> |
Cc: | fuboat(at)outlook(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18617: PostgreSQL Server Subprocess Crashes by the XPATH Function Expression with Crafted Arguments |
Date: | 2024-09-13 23:57:04 |
Message-ID: | 160394.1726271824@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> I filed a new report at
> https://gitlab.gnome.org/GNOME/libxml2/-/issues/799
Based on Nick Wellnhofer's response there, I've experimented with the
attached WIP patch, and it does seem to prevent the problem as long as
you have a non-ancient libxml2. This is only WIP because there are
other xmlXPathCompile calls we'd have to fix.
Sadly, still-popular distros like RHEL8 have "ancient" libxml2
versions, but that means they're exposed to the original bug not
only this variant. It seems to me to be worth masking the bug
where we can, though.
Nick also suggested that we not bother with a separate xmlXPathCompile
call if we're just going to throw away the compiled expression after
one use. Perhaps that's good cleanup, not sure. I don't know if
anyone has serious ambitions of re-using the compiled XPath
expressions.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
libxml2-stack-overrun-fix-wip.patch | text/x-diff | 535 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-09-14 14:42:03 | Re: pl/perl extension fails on Windows |
Previous Message | Tom Lane | 2024-09-13 19:45:11 | Re: BUG #18616: Long-running hash index build can not be interrupted |