Re: Fix small psql slash option leaks

On Wed, Aug 12, 2026 at 9:01 PM Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> Could psql_scan_slash_option() return the static oom_buffer when
> initPQExpBuffer() fails while parsing a quoted option? If so, the
> caller's free() would be invalid.

Yes, you're right! On out-of-memory, psql_scan_slash_option() can return
the static oom_buffer, so a caller that frees the returned pointer can
trigger an invalid free. I found that psql_scan_slash_command() has
the same kind of issue.

This is separate from the leak fixed by the original patch. Existing
callers can already free the results of these functions, so this
should be fixed independently.

Attached are three patches:

- 0001 fixes the psql_scan_slash_command() case.
- 0002 fixes the psql_scan_slash_option() case.
- 0003 is the original leak fix, unchanged.

The first two patches make, on OOM, these functions report "out of memory"
with pg_log_error() and return NULL instead of oom_buffer, preventing
callers from passing the static buffer to free().

One limitation of 0002 is that NULL from psql_scan_slash_option() can
still mean either "no option" or OOM. I considered adding machinery to
distinguish the two cases and updating all callers accordingly, but that
seemed unnecessarily large and complex for this issue.

So, for now, I think returning NULL after reporting the out-of-memory
error is a reasonable small fix, at least for the stable branches.
Even if a caller treats the NULL as no option, the user will still see
the out-of-memory error message output via that pg_log_error().

Thoughts?

Regards,

--
Fujii Masao