From: Tom Lane Date: Wed, 23 Apr 2025 20:04:42 +0000 (-0400) Subject: Avoid possibly-theoretical OOM crash hazard in hash_create(). X-Git-Tag: REL_16_9~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f45bdb13397fc142bc95513783dca3e0106e57af;p=thirdparty%2Fpostgresql.git Avoid possibly-theoretical OOM crash hazard in hash_create(). One place in hash_create() used DynaHashAlloc() as a convenient shorthand for MemoryContextAlloc(). That was fine when it was written, but it stopped being fine when 9c911ec06 changed DynaHashAlloc() to use MCXT_ALLOC_NO_OOM (mea culpa). Change the code to call plain MemoryContextAlloc() as intended. I think that this bug may be unreachable in practice, since we now always create AllocSets with some space already allocated, so that an OOM failure here for a non-shared hash table should be impossible (with a hash table name of reasonable length anyway). And there aren't enough shared hash tables to make a crash for one of those probable. Nonetheless it's clearly not operating as designed, so back-patch to v16 where 9c911ec06 came in. Reported-by: Maksim Korotkov Author: Tom Lane Discussion: https://postgr.es/m/219bdccd460510efaccf90b57e5e5ef2@postgrespro.ru Backpatch-through: 16 --- diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c index 012d4a0b1fd..da77a6bbd3f 100644 --- a/src/backend/utils/hash/dynahash.c +++ b/src/backend/utils/hash/dynahash.c @@ -388,7 +388,8 @@ hash_create(const char *tabname, long nelem, const HASHCTL *info, int flags) } /* Initialize the hash header, plus a copy of the table name */ - hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) + 1); + hashp = (HTAB *) MemoryContextAlloc(CurrentDynaHashCxt, + sizeof(HTAB) + strlen(tabname) + 1); MemSet(hashp, 0, sizeof(HTAB)); hashp->tabname = (char *) (hashp + 1);