Thread

to_char() vs. long numeric formatting strings from locale

Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-21T17:00:21Z

The numeric variants of to_char() allocate an output buffer of 8 bytes
per format character, reasoning that no format code can produce more
than that much output.  In general this is true, but there is a
potential exception: format codes L, G, and so on emit verbatim copies
of the currency_symbol, thousands_sep, etc strings from the active
LC_NUMERIC locale, and there's not an a-priori upper limit on the
lengths of those strings.  So in principle you could get a buffer
overrun.

I'm not aware of any real-world locales having such strings that
exceed 8 bytes, so it seems like we can close off this risk with
minimal effort by just truncating the locale's strings at 8 bytes,
as attached.

This bug was reported to pgsql-security by Xint Code as a potential
security issue.  However we decided it doesn't seem worth the CVE
treatment, because exploiting it would require getting a malicious
locale definition installed underneath a PG server.  That's a big ask
considering that locale definitions normally come from platform-owned
directories.  (On some platforms you might be able to point a program
at some other locale data source using an environment variable ... but
if you can control the server's environment then there are far more
powerful attacks available, eg via changing PATH or LD_LIBRARY_PATH.)

Despite that, it seems worth fixing as a run-of-the-mill bug.
Any objections to the attached?

			regards, tom lane