Re: pg_parse_json() should not leak token copies on failure

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: jacob(dot)champion(at)enterprisedb(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_parse_json() should not leak token copies on failure
Date: 2024-06-04 04:32:31
Message-ID: 20240604.133231.1552278213246079101.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

At Fri, 24 May 2024 08:43:01 -0700, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote in
> On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> > Attached is a draft patch to illustrate what I mean, but it's
> > incomplete: it only solves the problem for scalar values.
>
> (Attached is a v2 of that patch; in solving a frontend leak I should
> probably not introduce a backend segfault.)

I understand that the part enclosed in parentheses refers to the "if
(ptr) pfree(ptr)" structure. I believe we rely on the behavior of
free(NULL), which safely does nothing. (I couldn't find the related
discussion due to a timeout error on the ML search page.)

Although I don't fully understand the entire parser code, it seems
that the owner transfer only occurs in JSON_TOKEN_STRING cases. That
is, the memory pointed by scalar_val would become dangling in
JSON_TOKEN_NUBMER cases. Even if this is not the case, the ownership
transition apperas quite callenging to follow.

It might be safer or clearer to pstrdup the token in jsonb_in_scalar()
and avoid NULLifying scalar_val after calling callbacks, or to let
jsonb_in_sclar() NULLify the pointer.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-06-04 04:51:30 Re: Pgoutput not capturing the generated columns
Previous Message Amit Kapila 2024-06-04 04:07:09 Re: Conflict Detection and Resolution