pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). 7+ messages / 1 participants [nested] [flat]
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d5622acb32b3c11a27b323138fbee9c715742b38 Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b9645dca10995abb54a9e12bee6c9db579229c24 Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4c9bf947a9ecccc8fc6f7f531530656c5b99a93c Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/634804885f334c4125134147a05a074e600598aa Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7721fff06cc52a1208d628310ce40c3698baa2cb Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4310dfa254e9de9b5fbecbc54ef512187a9e1d09 Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). @ 2024-09-15 17:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-15 17:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). In existing releases of libxml2, xmlXPathCompile can be driven to stack overflow because it fails to protect itself against too-deeply-nested input. While there is an upstream fix as of yesterday, it will take years for that to propagate into all shipping versions. In the meantime, we can protect our own usages basically for free by calling xmlXPathCtxtCompile instead. (The actual bug is that libxml2 keeps its nesting counter in the xmlXPathContext, and its parsing code was willing to just skip counting nesting levels if it didn't have a context. So if we supply a context, all is well. It seems odd actually that it works at all to not supply a context, because this means that XPath parsing does not have access to XML namespace info. Apparently libxml2 never checks namespaces until runtime? Anyway, this seems like good future-proofing even if its only immediate effect is to dodge a bug.) Sadly, this hack only offers protection with libxml2 2.9.11 and newer. Before that there are multiple similar problems, so if you are processing untrusted XML it behooves you to get a newer version. But we have some pretty old libxml2 in the buildfarm, so it seems impractical to add a regression test to verify this fix. Per bug #18617 from Jingzhou Fu. Back-patch to all supported versions. Discussion: https://postgr.es/m/18617-1cee4d2ed1f4e7ae@postgresql.org Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0206795d2595e60117dbb4729e2f0ba904b39bd6 Modified Files -------------- contrib/xml2/xpath.c | 4 ++-- src/backend/utils/adt/xml.c | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-09-15 17:33 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us> 2024-09-15 17:33 pgsql: Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile(). Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox