public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix encoding length for EUC_CN. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:06 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:06 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/af79c30dc3e5369cd6d2bfdccd2c2c0ffbd60ef3 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:07 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:07 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/df0852fe037246289cc00b4d36da6c1f25ff5844 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:07 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:07 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/838248b1bf6b20762d13878006a404c27189f326 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:07 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:07 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/70ff9ede5ad7a2636bc15b03373535ab990fd254 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:07 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:07 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b2c81ac8678ce2e570db0843f48f50a971af28c5 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix encoding length for EUC_CN. @ 2026-02-09 00:08 Thomas Munro <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Thomas Munro @ 2026-02-09 00:08 UTC (permalink / raw) To: [email protected] Fix encoding length for EUC_CN. While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the mb<->wchar conversion functions allow 3-byte sequences beginning SS2, SS3. Change pg_encoding_max_length() to return 3, not 2, to close a hypothesized buffer overrun if a corrupted string is converted to wchar and back again in a newly allocated buffer. We might reconsider that in master (ie harmonizing in a different direction), but this change seems better for the back-branches. Also change pg_euccn_mblen() to report SS2 and SS3 characters as having length 3 (following the example of EUC_KR). Even though such characters would not pass verification, it's remotely possible that invalid bytes could be used to compute a buffer size for use in wchar conversion. Security: CVE-2026-2006 Backpatch-through: 14 Author: Thomas Munro <[email protected]> Reviewed-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2a53db21eea7b4db0285f6a44a165def2d3f6531 Modified Files -------------- src/common/wchar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-09 00:08 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-09 00:06 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]> 2026-02-09 00:07 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]> 2026-02-09 00:07 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]> 2026-02-09 00:07 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]> 2026-02-09 00:07 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]> 2026-02-09 00:08 pgsql: Fix encoding length for EUC_CN. Thomas Munro <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox