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
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 |