Re: pg_parse_json() should not leak token copies on failure - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: pg_parse_json() should not leak token copies on failure
Date
Msg-id 20240604.133231.1552278213246079101.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pg_parse_json() should not leak token copies on failure  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: pg_parse_json() should not leak token copies on failure
List pgsql-hackers
Hi,

At Fri, 24 May 2024 08:43:01 -0700, Jacob Champion <jacob.champion@enterprisedb.com> wrote in 
> On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion
> <jacob.champion@enterprisedb.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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Conflict Detection and Resolution
Next
From: Peter Smith
Date:
Subject: Re: Pgoutput not capturing the generated columns