Re: use-after-free in jsonb_set_lax()

Hi John,

> I didn't find any other places in the code base with a similar bug,
> but of course I can't be certain.

I swept for siblings and found none. Of the 444 writes to
fcinfo->args[] in the backend, all go into a frame the function built
itself or an executor/planner frame, except 15 into a caller-supplied
frame; jsonb_set_lax is the only SQL-callable one among those. Const
args are written once at expression init in the expected places
(ExecInitFunc, the JSON constructors). Same on 14-17. A differential
multi-row vs per-row fuzz over the jsonb family (132k cases, cassert
and ASan) only ever fires in jsonb_set_lax, and is clean with v1.

One note on severity, in case it affects the classification: the
read-after-free reaches the output, not just control flow. Under ASan
the thread's repro does not crash; it silently returns {"a": null}
instead of {}, since the freed null stays in the per-tuple keeper
block. The 3-argument form jsonb_set_lax(col, path, NULL) over two
rows returns bytes of freed memory inside the result value (on a
cassert build); on a non-assert build that is reused heap, so it looks
able to disclose memory contents, not only crash or return wrong data.
Allocating ~5 kB per row turns it into a clean heap-use-after-free at
the !PG_ARGISNULL(2) shortcut. v1 is clean on all of it.

Regards,
Manu