agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Guard against unsafe conditions in usage of pg_strftime(). 6+ messages / 1 participants [nested] [flat]
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ec8ded4b327f9d121811f43bf0177d0f289c3949 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c6e7a9ef30a2c97cc2dee8915f5e9e3675c81b34 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a386d14feb210cd9c6c9b68cd8782e089f4d5b62 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/79b7847c729bcbbe7ae2af1742adc6db86904932 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c3fff3950f215732365c379bb87bc13d453eb4a5 Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Guard against unsafe conditions in usage of pg_strftime(). @ 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 Guard against unsafe conditions in usage of pg_strftime(). Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2c8226f52b4258e9e55185dce11d58a40c66663a Author: Tom Lane <tgl@sss.pgh.pa.us> Modified Files -------------- src/timezone/strftime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) ^ 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: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com> 2026-05-11 12:19 pgsql: Guard against unsafe conditions in usage of pg_strftime(). Noah Misch <noah@leadboat.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox