pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed[Patch] Fix bounds check in trim_array()
3+ messages / 3 participants
[nested] [flat]
* [Patch] Fix bounds check in trim_array()
@ 2022-07-25 14:40 Martin Kalcher <martin.kalcher@aboutsource.net>
2022-07-28 22:46 ` Re: [Patch] Fix bounds check in trim_array() Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Martin Kalcher @ 2022-07-25 14:40 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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.patch (text/x-patch, 1.9K) download
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
* Re: [Patch] Fix bounds check in trim_array()
2022-07-25 14:40 [Patch] Fix bounds check in trim_array() Martin Kalcher <martin.kalcher@aboutsource.net>
@ 2022-07-28 22:46 ` Nathan Bossart <nathandbossart@gmail.com>
2022-07-31 17:25 ` Re: [Patch] Fix bounds check in trim_array() Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Nathan Bossart @ 2022-07-28 22:46 UTC (permalink / raw)
To: Martin Kalcher <martin.kalcher@aboutsource.net>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [Patch] Fix bounds check in trim_array()
2022-07-25 14:40 [Patch] Fix bounds check in trim_array() Martin Kalcher <martin.kalcher@aboutsource.net>
2022-07-28 22:46 ` Re: [Patch] Fix bounds check in trim_array() Nathan Bossart <nathandbossart@gmail.com>
@ 2022-07-31 17:25 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2022-07-31 17:25 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Martin Kalcher <martin.kalcher@aboutsource.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-07-31 17:25 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-07-25 14:40 [Patch] Fix bounds check in trim_array() Martin Kalcher <martin.kalcher@aboutsource.net>
2022-07-28 22:46 ` Nathan Bossart <nathandbossart@gmail.com>
2022-07-31 17:25 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox