]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Make palloc_array() and friends safe against integer overflow.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 11 May 2026 12:13:46 +0000 (05:13 -0700)
committerNoah Misch <noah@leadboat.com>
Mon, 11 May 2026 12:13:46 +0000 (05:13 -0700)
commit46593aea0a5ca7ead0876833d99639c9a4bb5a9d
tree10d3d92a82c3cae513f2196df42092cdeb05902d
parentd388e1d7f0468db8d046f9101f972d1fa988b19a
Make palloc_array() and friends safe against integer overflow.

Sufficiently large "count" arguments could result in undetected
overflow, causing the allocated memory chunk to be much smaller
than what the caller will subsequently write into it.  This is
unlikely to be a hazard with 64-bit size_t but can sometimes
happen on 32-bit builds, primarily where a function allocates
workspace that's significantly larger than its input data.
Rather than trying to patch the at-risk callers piecemeal,
let's just redefine these macros so that they always check.

To do that, move the longstanding add_size() and mul_size() functions
into palloc.h and mcxt.c, and adjust them to not be specific to
shared-memory allocation.  Then invent palloc_mul(), palloc0_mul(),
palloc_mul_extended() to use these functions.  Actually, the latter
use inlined copies to save one function call.  repalloc_array() gets
similar treatment.  I didn't bother trying to inline the calls for
repalloc0_array() though.

In v14 and v15, this also adds repalloc_extended(), which previously
was only available in v16 and up.

We need copies of all this in fe_memutils.[hc] as well, since that
module also provides palloc_array() etc.

Reported-by: Xint Code
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Backpatch-through: 14
Security: CVE-2026-6473
src/backend/storage/ipc/shmem.c
src/backend/utils/mmgr/mcxt.c
src/common/fe_memutils.c
src/include/common/fe_memutils.h
src/include/storage/shmem.h
src/include/utils/memutils.h
src/include/utils/palloc.h