[Patch] Fix bounds check in trim_array()
Hi,
while working on something else i encountered a bug in the trim_array()
function. The bounds check fails for empty arrays without any
dimensions. It reads the size of the non existing first dimension to
determine the arrays length.
select trim_array('{}'::int[], 10);
------------
{}
select trim_array('{}'::int[], 100);
ERROR: number of elements to trim must be between 0 and 64
The attached patch fixes that check.
Martin
Attachments:
0001-Fix-bounds-check-in-trim_array.patchtext/x-patch; charset=UTF-8; name=0001-Fix-bounds-check-in-trim_array.patchDownload
From b6173a8f8f94cddd5347db482b8e4480c0e546e7 Mon Sep 17 00:00:00 2001
From: Martin Kalcher <martin.kalcher@aboutsource.net>
Date: Mon, 25 Jul 2022 16:26:14 +0200
Subject: [PATCH] Fix bounds check in trim_array()
The bounds check in trim_array() failed for empty arrays without any
dimension. It read the size of the first dimension without checking its
existence.
---
src/backend/utils/adt/arrayfuncs.c | 2 +-
src/test/regress/expected/arrays.out | 2 ++
src/test/regress/sql/arrays.sql | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/backend/utils/adt/arrayfuncs.c b/src/backend/utils/adt/arrayfuncs.c
index fb167f226a..0342ebf4fd 100644
--- a/src/backend/utils/adt/arrayfuncs.c
+++ b/src/backend/utils/adt/arrayfuncs.c
@@ -6839,7 +6839,7 @@ trim_array(PG_FUNCTION_ARGS)
{
ArrayType *v = PG_GETARG_ARRAYTYPE_P(0);
int n = PG_GETARG_INT32(1);
- int array_length = ARR_DIMS(v)[0];
+ int array_length = (ARR_NDIM(v) > 0) ? ARR_DIMS(v)[0] : 0;
int16 elmlen;
bool elmbyval;
char elmalign;
diff --git a/src/test/regress/expected/arrays.out b/src/test/regress/expected/arrays.out
index ce6f3a65f9..97920f38c2 100644
--- a/src/test/regress/expected/arrays.out
+++ b/src/test/regress/expected/arrays.out
@@ -2445,3 +2445,5 @@ SELECT trim_array(ARRAY[1, 2, 3], -1); -- fail
ERROR: number of elements to trim must be between 0 and 3
SELECT trim_array(ARRAY[1, 2, 3], 10); -- fail
ERROR: number of elements to trim must be between 0 and 3
+SELECT trim_array(ARRAY[]::int[], 1); -- fail
+ERROR: number of elements to trim must be between 0 and 0
diff --git a/src/test/regress/sql/arrays.sql b/src/test/regress/sql/arrays.sql
index f774faf856..791af5c0ce 100644
--- a/src/test/regress/sql/arrays.sql
+++ b/src/test/regress/sql/arrays.sql
@@ -754,3 +754,4 @@ FROM
SELECT trim_array(ARRAY[1, 2, 3], -1); -- fail
SELECT trim_array(ARRAY[1, 2, 3], 10); -- fail
+SELECT trim_array(ARRAY[]::int[], 1); -- fail
--
2.37.1
On Mon, Jul 25, 2022 at 04:40:51PM +0200, Martin Kalcher wrote:
+SELECT trim_array(ARRAY[]::int[], 1); -- fail +ERROR: number of elements to trim must be between 0 and 0
Can we improve the error message? Maybe it should look something like
ERROR: number of elements to trim must be 0
for this case.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Nathan Bossart <nathandbossart@gmail.com> writes:
On Mon, Jul 25, 2022 at 04:40:51PM +0200, Martin Kalcher wrote:
+SELECT trim_array(ARRAY[]::int[], 1); -- fail +ERROR: number of elements to trim must be between 0 and 0
Can we improve the error message? Maybe it should look something like
ERROR: number of elements to trim must be 0
for this case.
Hmm, I'm unexcited about making our long-suffering translators
deal with another translatable string for such a corner case.
I think it's fine as-is.
A bigger problem is that a little further down, there's an equally
unprotected reference to ARR_LBOUND(v)[0]. Now, the fact that that
expression computes garbage doesn't matter too much, because AFAICS
if the array is zero-D then array_get_slice is going to exit at
if (ndim < nSubscripts || ndim <= 0 || ndim > MAXDIM)
return PointerGetDatum(construct_empty_array(elemtype));
without ever examining its upperIndx[] argument. However,
once we put in a test case covering this behavior, I bet that
valgrind-using buildfarm animals will start to bleat about the
invalid memory access. I think the easiest fix is like
if (ARR_NDIM(v) > 0)
{
upper[0] = ARR_LBOUND(v)[0] + array_length - n - 1;
upperProvided[0] = true;
}
It'd be good to get this fix into next week's minor releases,
so I'll go push it.
regards, tom lane