From f864a4cdfcec1de50ef969772a59daeed39c4a1d Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Feb 2025 12:46:35 -0500 Subject: [PATCH] In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. --- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/fe_utils/string_utils.c b/src/fe_utils/string_utils.c index 8b112088fbe..b2301dd8c5d 100644 --- a/src/fe_utils/string_utils.c +++ b/src/fe_utils/string_utils.c @@ -200,11 +200,13 @@ fmtIdEnc(const char *rawid, int encoding) * easier for users to find the invalidly encoded portion of a * larger string. */ - enlargePQExpBuffer(id_return, 2); - pg_encoding_set_invalid(encoding, - id_return->data + id_return->len); - id_return->len += 2; - id_return->data[id_return->len] = '\0'; + if (enlargePQExpBuffer(id_return, 2)) + { + pg_encoding_set_invalid(encoding, + id_return->data + id_return->len); + id_return->len += 2; + id_return->data[id_return->len] = '\0'; + } /* * Handle the following bytes as if this byte didn't exist. -- 2.30.2