On Thu, Aug 13, 2026 at 2:03 AM Fujii Masao <[email protected]> wrote: > > On Wed, Aug 12, 2026 at 9:01 PM Junwang Zhao <[email protected]> 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
