supabase / supautils / 32943776920

94%

push

github

Merge commit from fork

* fix: CVE-2026-14669

Problem
-------

Check https://www.postgresql.org/support/security/CVE-2026-14669/.

The root cause of the CVE is that the `timezone` GUC accepts long values
that overflow `to_char`.

The [patch in pg](https://github.com/postgres/postgres/commit/3d724bf4f) solves it like this:

```
postgres=# set timezone = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0';
SET
postgres=# select to_char(timestamptz '2000-01-15 12:00:00+00', 'TZ');
2026-08-24 19:27:49.310 -05 [115381] ERROR:  time zone format value too long
2026-08-24 19:27:49.310 -05 [115381] STATEMENT:  select to_char(timestamptz '2000-01-15 12:00:00+00', 'TZ');
ERROR:  time zone format value too long
```

Newer versions don't give the error since they solve it by using
StringInfo ([ref](https://github.com/postgres/postgres/commit/03d2554638c)) which uses an expansible buffer instead.

Solution
--------

Instead of failing at `to_char` time, we do it when setting the
`timezone` GUC via check hook:

```sql
set timezone = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0';
ERROR:  timezone values cannot be longer than 24 bytes
```

This way `to_char` doesn't overflow since the long timezone doesn't
reach it.

Notes
-----

- Limitation: some valid timezones are rejected, like `posix/America/Argentina/ComodRivadavia`. In theory we could be more sophisticated with our parsing and only reject POSIX values,
  but IMO this is dangerous business, so the fix is kept as simple as possible.
- For suabase prod, the list of all rejected timezones are these: `select length(name), * from pg_timezone_names where length(name) > 24;`:

| length | name                                   | abbrev | utc_offset | is_dst |
| ------ | -------------------------------------- | ------ | ---------- | ------ |
| 25     | Antarctica/DumontDUrville              | +10    | 10:00:00   | false  |
| 26     | posix/Africa/Dar_es_Salaam             | EAT    | 03:00:00   | fals... (continued)

45 of 47 new or added lines in 2 files covered. (95.74%)

1412 of 1502 relevant lines covered (94.01%)

254.15 hits per line