pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Prevent buffer overrun in unicode_normalize(). 6+ messages / 1 participants [nested] [flat]
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/066b7b144f33819b0f4efa6b24ec638974c79a8a Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8d1489d505cf97357d27a69da020390eb6d7018b Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ebcfa7867fb5f3acb906fda77b5cf0282d9ad81a Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f20b840813f579062cc5de0a9a266dc8d5590fc7 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b11c3eadf765664a9b5b6d099f05fc26efbb5a83 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent buffer overrun in unicode_normalize(). @ 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 Prevent buffer overrun in unicode_normalize(). Some UTF8 characters decompose to more than a dozen codepoints. It is possible for an input string that fits into well under 1GB to produce more than 4G decomposed codepoints, causing unicode_normalize()'s decomp_size variable to wrap around to a small positive value. This results in a small output buffer allocation and subsequent buffer overrun. To fix, test after each addition to see if we've overrun MaxAllocSize, and break out of the loop early if so. In frontend code we want to just return NULL for this failure (treating it like OOM). In the backend, we can rely on the following palloc() call to throw error. I also tightened things up in the calling functions in varlena.c, using size_t rather than int and allocating the input workspace with palloc_array(). These changes are probably unnecessary given the knowledge that the original input and the normalized output_chars array must fit into 1GB, but it's a lot easier to believe the code is safe with these changes. Reported-by: Xint Code Reported-by: Bruce Dang <bruce@calif.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 14 Security: CVE-2026-6473 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3e0eba19675404ce873cbeadfaff8c99ec94d012 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/backend/utils/adt/varlena.c | 14 +++++++------- src/common/unicode_norm.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 7 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: Prevent buffer overrun in unicode_normalize(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Prevent buffer overrun in unicode_normalize(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Prevent buffer overrun in unicode_normalize(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Prevent buffer overrun in unicode_normalize(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Prevent buffer overrun in unicode_normalize(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Prevent buffer overrun in unicode_normalize(). 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