Feedback-ID: i0c21471d:Fastmail
MIME-Version: 1.0
Date: Thu, 10 Apr 2025 15:17:17 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: 
 =?UTF-8?Q?=D0=94=D0=B0=D0=BD=D0=B8=D0=B8=D0=BB_=D0=AD=D0=BB=D0=B8=D1=88?=
 =?UTF-8?Q?=D0=B0=D0=BA=D0=BE=D0=B2?= <dan-eli@mail.ru>,
 pgsql-bugs@lists.postgresql.org
Message-Id: <bfdf6ae4-7d27-4a1c-99b3-b6307637f106@app.fastmail.com>
In-Reply-To: <18888-31bcf4436ea6a20d@postgresql.org>
References: <18888-31bcf4436ea6a20d@postgresql.org>
Subject: Re: BUG #18888: /src/interfaces/ecpg/preproc/descriptor.c possible
 NULL
 dereference
Content-Type: multipart/alternative;
 boundary=619177c18aa64af7a6eed0e4351a1b75
Archived-At: 
 <https://www.postgresql.org/message-id/bfdf6ae4-7d27-4a1c-99b3-b6307637f106%40app.fastmail.com>
Precedence: bulk

--619177c18aa64af7a6eed0e4351a1b75
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, Apr 10, 2025, at 1:39 PM, PG Bug reporting form wrote:
> On 203 and 313 lines It seems that a struct data type should not be used in
> 'EXEC SQL SET DESCRIPTOR' command, so the code in question should never be
> executed and it is not a problem. However there are no actual checks for
> corrrectess of the provided data type. It is required to add a check against
> wrong data types supplied by the user.

Which struct data type? struct variable?

Did you read find_variable()? At the end, it has

    if (p == NULL)
        mmfatal(PARSE_ERROR, "variable \"%s\" is not declared", name);

    return p;

mmfatal() is marked as noreturn so it is not possible that find_variable()
returns NULL. Hence, struct variable *v is always a valid pointer.

If you're directly opening bug reports based on a static analyzer output
without a previous analysis, don't do that. These SATs generally report lots of
false positives. Instead, investigate each report and (if possible) create a
reproducible test case demonstrating that it is a real issue.

--
Euler Taveira
EDB   https://www.enterprisedb.com/

--619177c18aa64af7a6eed0e4351a1b75
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Apr 10,=
 2025, at 1:39 PM, PG Bug reporting form wrote:</div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 203 and 313 lines It seems that a st=
ruct data type should not be used in</div><div>'EXEC SQL SET DESCRIPTOR'=
 command, so the code in question should never be</div><div>executed and=
 it is not a problem. However there are no actual checks for</div><div>c=
orrrectess of the provided data type. It is required to add a check agai=
nst</div><div>wrong data types supplied by the user.<br></div></blockquo=
te><div><br></div><div>Which struct data type? struct variable?</div><di=
v><br></div><div>Did you read find_variable()? At the end, it has</div><=
div><br></div><div>&nbsp;&nbsp;&nbsp; if (p =3D=3D NULL)</div><div>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mmfatal(PARSE_ERROR, "variable \"%=
s\" is not declared", name);</div><div><br></div><div>&nbsp;&nbsp;&nbsp;=
 return p;</div><div><br></div><div>mmfatal() is marked as noreturn so i=
t is not possible that find_variable()</div><div>returns NULL. Hence, st=
ruct variable *v is always a valid pointer.</div><div><br></div><div>If =
you're directly opening bug reports based on a static analyzer output</d=
iv><div>without a previous analysis, don't do that. These SATs generally=
 report lots of</div><div>false positives. Instead, investigate each rep=
ort and (if possible) create a</div><div>reproducible test case demonstr=
ating that it is a real issue.</div><div><br></div><div id=3D"sig1124090=
80"><div class=3D"signature">--</div><div class=3D"signature">Euler Tave=
ira</div><div class=3D"signature">EDB&nbsp;&nbsp; <a href=3D"https://www=
.enterprisedb.com/">https://www.enterprisedb.com/</a></div></div><div><b=
r></div></body></html>
--619177c18aa64af7a6eed0e4351a1b75--