MIME-Version: 1.0
References: <19524-9559d302c8455664@postgresql.org>
 <CAJTYsWXZYpz872NHTaWjAvQ2C-nFTDibzpHx9EBhPzq8Rgftmw@mail.gmail.com>
 <AIUAtwB5Kv6TL*RnfwYEJqqJ.3.1781790203264.Hmail.3020001251@tju.edu.cn>
 <CAJTYsWWE_xDdREp6EcvH3vVO8zaWbKJzjMyVisVy8VS9_ijYnQ@mail.gmail.com>
 <AG*ALwD0Kq*Tcll8fCWm7Kq6.3.1781791367878.Hmail.3020001251@tju.edu.cn>
In-Reply-To: 
 <AG*ALwD0Kq*Tcll8fCWm7Kq6.3.1781791367878.Hmail.3020001251@tju.edu.cn>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Thu, 18 Jun 2026 19:53:37 +0530
Message-ID: 
 <CAJTYsWVcj3HG-CTBzOSJ5AjyTOUpY9oTZG0wofyY+40DASdM1Q@mail.gmail.com>
Subject: Re: BUG #19524: In `contrib/btree_gist` float4/float8 GiST index
 operations, handling NaN values with raw C operator
To: =?UTF-8?B?546L6LeD5p6X?= <violin0613@tju.edu.cn>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000b6256e065487ec5b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWVcj3HG-CTBzOSJ5AjyTOUpY9oTZG0wofyY%2B40DASdM1Q%40mail.gmail.com>
Precedence: bulk

--000000000000b6256e065487ec5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, 18 Jun 2026 at 19:32, =E7=8E=8B=E8=B7=83=E6=9E=97 <violin0613@tju.e=
du.cn> wrote:

> In addition to the index scan inconsistency you described, I found two
> further security-relevant effects from the same root cause.
>
> Effect 1: EXCLUDE constraint bypass (float4)
>
> CREATE TABLE reservations (
>
> room float4,
>
> during tsrange,
>
> EXCLUDE USING gist (room WITH =3D, during WITH &&)
>
> );
>
> INSERT INTO reservations VALUES ('NaN'::float4, '[2025-01-01,2025-01-02)'=
);
>
> INSERT INTO reservations VALUES ('NaN'::float4, '[2025-01-01,2025-01-02)'=
);
>
> SELECT COUNT(*) FROM reservations;
>
> Expected: 1 (second insert blocked). Actual: 2. The EXCLUDE constraint is
> silently bypassed for NaN values, allowing duplicate conflicting rows to =
be
> inserted.
>
> Effect 2: RLS bypass (float8)
>
> CREATE TABLE measurements (id int, val float8);
>
> CREATE INDEX ON measurements USING gist (val);
>
> INSERT INTO measurements VALUES (1, 'NaN'), (2, 1.5);
>
> ALTER TABLE measurements ENABLE ROW LEVEL SECURITY;
>
> ALTER TABLE measurements FORCE ROW LEVEL SECURITY;
>
> CREATE POLICY hide_nan ON measurements FOR SELECT USING (val !=3D
> 'NaN'::float8);
>
> CREATE ROLE lowpriv LOGIN;
>
> GRANT SELECT ON measurements TO lowpriv;
>
> SET ROLE lowpriv;
>
> SET enable_seqscan =3D off;
>
> SET enable_bitmapscan =3D off;
>
> SELECT * FROM measurements ORDER BY id;
>
> Expected: only (2, 1.5). Actual: both rows including (1, NaN). The RLS
> policy is bypassed when the GiST index is used because
> gbt_float8_consistent() sets *recheck =3D false unconditionally, so the
> heap-level RLS filter is never applied.
>
> The root cause is that gbt_float8eq(NaN, NaN) returns false due to IEEE
> 754 semantics, causing BtreeGistNotEqualStrategyNumber in
> btree_utils_num.c:300 to incorrectly conclude that NaN satisfies !=3D NaN=
.
> The fix (replacing raw C operators with float8_cmp_internal) addresses bo=
th
> effects. As an additional defensive measure, *recheck in the consistent
> functions should be set to true when the query or key involves NaN.
>
I meant forwarding this on the other thread (BUG #19501)
which has been reported.

Regards,
Ayush

--000000000000b6256e065487ec5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 18 Jun 2=
026 at 19:32, =E7=8E=8B=E8=B7=83=E6=9E=97 &lt;<a href=3D"mailto:violin0613@=
tju.edu.cn">violin0613@tju.edu.cn</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><p>In addition to the index scan inconsist=
ency you described, I found two further security-relevant effects from the =
same root cause.</p><p></p><p>Effect 1: EXCLUDE constraint bypass (float4)<=
/p><p></p><p>CREATE TABLE reservations (</p><p>    room   float4,</p><p>   =
 during tsrange,</p><p>    EXCLUDE USING gist (room WITH =3D, during WITH &=
amp;&amp;)</p><p>);</p><p>INSERT INTO reservations VALUES (&#39;NaN&#39;::f=
loat4, &#39;[2025-01-01,2025-01-02)&#39;);</p><p>INSERT INTO reservations V=
ALUES (&#39;NaN&#39;::float4, &#39;[2025-01-01,2025-01-02)&#39;);</p><p>SEL=
ECT COUNT(*) FROM reservations;</p><p>Expected: 1 (second insert blocked). =
Actual: 2. The EXCLUDE constraint is silently bypassed for NaN values, allo=
wing duplicate conflicting rows to be inserted.</p><p></p><p>Effect 2: RLS =
bypass (float8)</p><p></p><p>CREATE TABLE measurements (id int, val float8)=
;</p><p>CREATE INDEX ON measurements USING gist (val);</p><p>INSERT INTO me=
asurements VALUES (1, &#39;NaN&#39;), (2, 1.5);</p><p>ALTER TABLE measureme=
nts ENABLE ROW LEVEL SECURITY;</p><p>ALTER TABLE measurements FORCE ROW LEV=
EL SECURITY;</p><p>CREATE POLICY hide_nan ON measurements FOR SELECT USING =
(val !=3D &#39;NaN&#39;::float8);</p><p>CREATE ROLE lowpriv LOGIN;</p><p>GR=
ANT SELECT ON measurements TO lowpriv;</p><p>SET ROLE lowpriv;</p><p>SET en=
able_seqscan =3D off;</p><p>SET enable_bitmapscan =3D off;</p><p>SELECT * F=
ROM measurements ORDER BY id;</p><p>Expected: only (2, 1.5). Actual: both r=
ows including (1, NaN). The RLS policy is bypassed when the GiST index is u=
sed because gbt_float8_consistent() sets *recheck =3D false unconditionally=
, so the heap-level RLS filter is never applied.</p><p></p><p>The root caus=
e is that gbt_float8eq(NaN, NaN) returns false due to IEEE 754 semantics, c=
ausing BtreeGistNotEqualStrategyNumber in btree_utils_num.c:300 to incorrec=
tly conclude that NaN satisfies !=3D NaN. The fix (replacing raw C operator=
s with float8_cmp_internal) addresses both effects. As an additional defens=
ive measure, *recheck in the consistent functions should be set to true whe=
n the query or key involves NaN.</p></blockquote><div>I meant forwarding th=
is on the other thread (BUG #19501) <br>which has=C2=A0<span style=3D"backg=
round-color:transparent">been reported.</span></div><div><br>Regards,<br>Ay=
ush=C2=A0</div></div></div>

--000000000000b6256e065487ec5b--