Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19603: Vuln47: distance_taxicab and distance_chebyshev silently
 return 0 instead of NaN when a cube coordin
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: 1217816127@qq.com
Reply-To: 1217816127@qq.com, pgsql-bugs@lists.postgresql.org
Date: Mon, 03 Aug 2026 07:00:47 +0000
Message-ID: <19603-7b1f783d5bbfe791@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19603-7b1f783d5bbfe791%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19603
Logged by:          Yuelin Wang
Email address:      1217816127@qq.com
PostgreSQL version: 19beta2
Operating system:   Linux (Ubuntu 24.04, x86_64)
Description:       =20

### Summary

The static helper distance_1D() in contrib/cube/cube.c classifies two
intervals as "left of", "right of", or "intersecting" using direct floating
point comparisons. When a coordinate is NaN, every comparison evaluates to
false, so the interval falls through to the intersecting branch and the
function returns 0.0 instead of NaN. distance_taxicab and distance_chebyshev
call distance_1D per dimension and sum or max the results, so a single NaN
coordinate silently produces a finite, plausible-looking distance instead of
propagating NaN as IEEE 754 arithmetic normally would.

CWE: CWE-1339. Severity: Low.

### PoC

```sql
CREATE EXTENSION cube;
SELECT distance_chebyshev('(nan,nan)'::cube, '(1,1)'::cube);
SELECT distance_chebyshev('(5,5)'::cube, '(1,nan)'::cube);
SELECT distance_taxicab('(nan)'::cube, '(1)'::cube);
```

### Result

Real captured output from the independent verification run:

```
CREATE EXTENSION
 distance_chebyshev
--------------------
                  0
(1 row)

 distance_chebyshev
--------------------
                  4
(1 row)

 distance_taxicab
------------------
                0
(1 row)
```

### Impact

A database user who stores or queries cube values containing NaN coordinates
can get silently wrong distance results (e.g. 0 instead of NaN) from
distance_taxicab and distance_chebyshev, which can corrupt nearest-neighbor
search results, ranking, or KNN-index-backed queries that rely on these
operators.