| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Avoid passing unintended format codes to snprintf(). |
| Date: | 2026-05-11 12:19:38 |
| Message-ID: | E1wMPbm-0002Xd-1Q@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Avoid passing unintended format codes to snprintf().
timeofday() assumed that the output of pg_strftime() could not contain
% signs, other than the one it explicitly asks for with %%. However,
we don't have that guarantee with respect to the time zone name (%Z).
A crafted time zone setting could abuse the subsequent snprintf()
call, resulting in crashes or disclosure of server memory.
To fix, split the pg_strftime() call into two and then treat the
outputs as literal strings, not a snprintf format string. The
extra pg_strftime() call doesn't really cost anything, since the
bulk of the conversion work was done by pg_localtime().
Also, adjust buffer widths so that we're not risking string truncation
during the snprintf() step, as that would create a hazard of producing
mis-encoded output.
This also fixes a latent portability issue: the format string expects
an int, but tp.tv_usec is long int on many platforms.
Reported-by: Xint Code
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Reviewed-by: John Naylor <johncnaylorls(at)gmail(dot)com>
Backpatch-through: 14
Security: CVE-2026-6474
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4197c880cada16a5ae2777cd4ef8522090376a77
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Modified Files
--------------
src/backend/utils/adt/timestamp.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2026-05-11 12:19:39 | pgsql: Check CREATE privilege on multirange type schema in CREATE TYPE. |
| Previous Message | Noah Misch | 2026-05-11 12:19:37 | pgsql: Harden our regex engine against integer overflow in size calcula |