Re: Fix small psql slash option leaks

On Thu, Aug 13, 2026 at 2:03 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> 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.

Yeah, \setenv NAME VALUE can interpret an OOM while parsing VALUE
as an omitted value and unset NAME.

>
> 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().

WFM.

>
> Thoughts?
>
> Regards,
>
> --
> Fujii Masao

--
Regards
Junwang Zhao