pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix assorted places that need to use palloc_array(). 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c55cea5290647c8d3e571893078664bbca955017 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 3 ++- src/common/blkreftable.c | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/01e568b8c11bc0e609cb2b1f936a0697d793703d Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 9 +++++---- src/common/blkreftable.c | 27 ++++++++++++++++++++------- 2 files changed, 25 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/01b5ef7df090c5921cbd373d80e100b1d529c656 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 9 +++++---- src/common/blkreftable.c | 27 ++++++++++++++++++++------- 2 files changed, 25 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/aff71f87ba78e8fe5fb266ecfce692f2e23a5d6a Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4032c9d98ab767fcbc5fa65b6ab1a39412b68912 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix assorted places that need to use palloc_array(). @ 2026-05-11 12:19 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-11 12:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix assorted places that need to use palloc_array(). multirange_recv and BlockRefTableReaderNextRelation were incautious about multiplying a possibly-large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t leading to an undersized allocation and buffer overrun. Fix these places by using palloc_array() instead of a handwritten multiplication. (In HEAD, some of them were fixed already, but none of that work got back-patched at the time.) In addition, BlockRefTableReaderNextRelation passes the same value to BlockRefTableRead's "int length" parameter. If built for 64-bit frontend code, palloc_array() allows a larger array size than it otherwise would, potentially allowing that parameter to overflow. Add an explicit check to forestall that and keep the behavior the same cross-platform. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e31ef072073f6b36e82197accd704ae428e6dd18 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/multirangetypes.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-11 12:19 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Fix assorted places that need to use palloc_array(). Noah Misch <noah@leadboat.com>
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