pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18614: [ECPG] out of bound in DecodeDateTime
12+ messages / 6 participants
[nested] [flat]
Commits from this thread:
2024-10-22 a0bff38d13 2c37cb26f8 a1e613b81a 335501fb2b 9a51d4af12 fcafbaadf7 9ecfd8a48a ecpg: Fix out-of-bound read in DecodeDateTime()
* BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-09-12 08:54 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 12+ messages in thread
From: PG Bug reporting form @ 2024-09-12 08:54 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: p.nekrasov@fobos-nt.ru
The following bug has been logged on the website:
Bug reference: 18614
Logged by: Pavel Nekrasov
Email address: p.nekrasov@fobos-nt.ru
PostgreSQL version: 17rc1
Operating system: Alt 10
Description:
in the line ```if (tm->tm_mday < 1 || tm->tm_mday >
day_tab[isleap(tm->tm_year)][tm->tm_mon - 1]) ``` tm->tm_mon may be equal to
0, which will result in reading by indexes -1
this is possible when calling PGTYPESdate_from_asc or
PGTYPEStimestamp_from_asc with "str" equal, for example, "AM95000062"
Patch:
inline patch 1: src/interfaces/ecpg/pgtypeslib/dt_common.c (+1/-2 lines) download inline-1.patch
--- a/src/interfaces/ecpg/pgtypeslib/dt_common.c
+++ b/src/interfaces/ecpg/pgtypeslib/dt_common.c
@@ -2327,10 +2327,9 @@ DecodeDateTime(char **field, int *ftype, int nf,
return ((fmask & DTK_TIME_M) == DTK_TIME_M) ? 1 : -1;
/*
- * check for valid day of month, now that we know for sure the month
- * and year...
+ * check for valid day of month and month, now that we know for sure the
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-14 21:52 Bruce Momjian <bruce@momjian.us>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2024-10-14 21:52 UTC (permalink / raw)
To: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Thu, Sep 12, 2024 at 08:54:42AM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18614
> Logged by: Pavel Nekrasov
> Email address: p.nekrasov@fobos-nt.ru
> PostgreSQL version: 17rc1
> Operating system: Alt 10
> Description:
>
> in the line ```if (tm->tm_mday < 1 || tm->tm_mday >
> day_tab[isleap(tm->tm_year)][tm->tm_mon - 1]) ``` tm->tm_mon may be equal to
> 0, which will result in reading by indexes -1
>
> this is possible when calling PGTYPESdate_from_asc or
> PGTYPEStimestamp_from_asc with "str" equal, for example, "AM95000062"
Yes, I agree. Attached is a non-word-wrapped patch that I plan to apply
to all supported PG versions.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
Attachments:
ecpg.diff (text/x-diff, 767B) download
diff --git a/src/interfaces/ecpg/pgtypeslib/dt_common.c b/src/interfaces/ecpg/pgtypeslib/dt_common.c
index 0d63fe52c5b..bf5976cf03b 100644
--- a/src/interfaces/ecpg/pgtypeslib/dt_common.c
+++ b/src/interfaces/ecpg/pgtypeslib/dt_common.c
@@ -2327,10 +2327,10 @@ DecodeDateTime(char **field, int *ftype, int nf,
return ((fmask & DTK_TIME_M) == DTK_TIME_M) ? 1 : -1;
/*
- * check for valid day of month, now that we know for sure the month
+ * check for valid day of month and month, now that we know for sure the month
* and year...
*/
- if (tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
+ if (tm->tm_mon < 1 || tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
return -1;
/*
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-16 00:18 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2024-10-16 00:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Mon, Oct 14, 2024 at 05:52:59PM -0400, Bruce Momjian wrote:
> /*
> - * check for valid day of month, now that we know for sure the month
> + * check for valid day of month and month, now that we know for sure the month
> * and year...
> */
> - if (tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
> + if (tm->tm_mon < 1 || tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
> return -1;
I would suggest adding a test. This is tricky enough and really easy
to miss, even if ECPG is not that touched these days.
There are a lot of callers of PGTYPEStimestamp_from_asc() in
dt_test.pgc that do sanity checks on such inputs.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-17 17:29 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2024-10-17 17:29 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Wed, Oct 16, 2024 at 09:18:10AM +0900, Michael Paquier wrote:
> On Mon, Oct 14, 2024 at 05:52:59PM -0400, Bruce Momjian wrote:
> > /*
> > - * check for valid day of month, now that we know for sure the month
> > + * check for valid day of month and month, now that we know for sure the month
> > * and year...
> > */
> > - if (tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
> > + if (tm->tm_mon < 1 || tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
> > return -1;
>
> I would suggest adding a test. This is tricky enough and really easy
> to miss, even if ECPG is not that touched these days.
>
> There are a lot of callers of PGTYPEStimestamp_from_asc() in
> dt_test.pgc that do sanity checks on such inputs.
Added in the attached patch. Is the output correct?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
Attachments:
ecpg.diff (text/x-diff, 4.0K) download
diff --git a/src/interfaces/ecpg/pgtypeslib/dt_common.c b/src/interfaces/ecpg/pgtypeslib/dt_common.c
index 0d63fe52c5b..51e35fee83b 100644
--- a/src/interfaces/ecpg/pgtypeslib/dt_common.c
+++ b/src/interfaces/ecpg/pgtypeslib/dt_common.c
@@ -2327,10 +2327,10 @@ DecodeDateTime(char **field, int *ftype, int nf,
return ((fmask & DTK_TIME_M) == DTK_TIME_M) ? 1 : -1;
/*
- * check for valid day of month, now that we know for sure the month
- * and year...
+ * check for valid day of month and month, now that we know for
+ * sure the month and year...
*/
- if (tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
+ if (tm->tm_mon < 1 || tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
return -1;
/*
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
index ee867b6dd86..1c4af713677 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
@@ -267,6 +267,11 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
printf("timestamp_to_asc3: %s\n", text);
PGTYPESchar_free(text);
+ ts1 = PGTYPEStimestamp_from_asc("AM95000062", NULL);
+ text = PGTYPEStimestamp_to_asc(ts1);
+ printf("timestamp_to_asc4: %s\n", text);
+ PGTYPESchar_free(text);
+
/* abc-03:10:35-def-02/11/94-gh */
/* 12345678901234567890123456789 */
@@ -453,16 +458,16 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
free(out);
{ ECPGtrans(__LINE__, NULL, "rollback");
-#line 381 "dt_test.pgc"
+#line 386 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 381 "dt_test.pgc"
+#line 386 "dt_test.pgc"
{ ECPGdisconnect(__LINE__, "CURRENT");
-#line 382 "dt_test.pgc"
+#line 387 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 382 "dt_test.pgc"
+#line 387 "dt_test.pgc"
return 0;
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
index 6e9ed3d3dba..0b81d27f5ba 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
@@ -42,7 +42,7 @@
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ecpg_get_data on line 38: RESULT: 2000-07-12 17:34:29 offset: -1; array: no
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ECPGtrans on line 381: action "rollback"; connection "ecpg1_regression"
+[NO_PID]: ECPGtrans on line 386: action "rollback"; connection "ecpg1_regression"
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ecpg_finish: connection ecpg1_regression closed
[NO_PID]: sqlca: code: 0, state: 00000
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
index 4b582fd7a28..ae07f6c591f 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
@@ -21,6 +21,7 @@ date_defmt_asc12: 0095-12-25
timestamp_to_asc1: 1996-02-29 00:00:00
timestamp_to_asc2: 1994-02-11 03:10:35
timestamp_to_asc3: 2000-01-01 00:00:00
+timestamp_to_asc4: 2000-01-01 00:00:00
timestamp_fmt_asc: 0: abc-00:00:00-def-01/01/00-ghi%
timestamp_defmt_asc(This is a 4/12/80 3-39l12test, This is a %m/%d/%y %H-%Ml%Stest) = 1980-04-12 03:39:12, error: 0
timestamp_defmt_asc(Tue Jul 22 17:28:44 +0200 2003, %a %b %d %H:%M:%S %z %Y) = 2003-07-22 15:28:44, error: 0
diff --git a/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc b/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
index f81a3926655..7f434e2b6b8 100644
--- a/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
+++ b/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
@@ -193,6 +193,11 @@ main(void)
printf("timestamp_to_asc3: %s\n", text);
PGTYPESchar_free(text);
+ ts1 = PGTYPEStimestamp_from_asc("AM95000062", NULL);
+ text = PGTYPEStimestamp_to_asc(ts1);
+ printf("timestamp_to_asc4: %s\n", text);
+ PGTYPESchar_free(text);
+
/* abc-03:10:35-def-02/11/94-gh */
/* 12345678901234567890123456789 */
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-18 05:51 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2024-10-18 05:51 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Thu, Oct 17, 2024 at 01:29:03PM -0400, Bruce Momjian wrote:
> Added in the attached patch. Is the output correct?
Well, no. The result in the regression test output you are producing
is a consequence that PGTYPEStimestamp_from_asc() returns
PGTYPES_TS_BAD_TIMESTAMP as errno with 0 as result. Hence, after
applying an offset this prints a timestamp with year 2000. What this
should report in the regression test output is the information about
the error happening, so the output that makes no sense because the
timestamp could not be understood.
> + ts1 = PGTYPEStimestamp_from_asc("AM95000062", NULL);
> + text = PGTYPEStimestamp_to_asc(ts1);
> + printf("timestamp_to_asc4: %s\n", text);
> + PGTYPESchar_free(text);
> +
> /* abc-03:10:35-def-02/11/94-gh */
> /* 12345678901234567890123456789 */
It is not entirely the fault of this patch, because the same error is
done a couple of lines above when using an incorrect hour number with
timestamp_to_asc3. The correct thing to do would be in the lines of
what num_test2.pgc does with its check_errno(), I think where we'd
check for the errno returned by PGTYPEStimestamp_from_asc() and
printf() its information in the output of the test. And we should do
that for both the old timestamp_to_asc3 and your new timestamp_to_asc4
if we want to be completely correct.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-22 05:53 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2024-10-22 05:53 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Fri, Oct 18, 2024 at 02:51:32PM +0900, Michael Paquier wrote:
> It is not entirely the fault of this patch, because the same error is
> done a couple of lines above when using an incorrect hour number with
> timestamp_to_asc3. The correct thing to do would be in the lines of
> what num_test2.pgc does with its check_errno(), I think where we'd
> check for the errno returned by PGTYPEStimestamp_from_asc() and
> printf() its information in the output of the test. And we should do
> that for both the old timestamp_to_asc3 and your new timestamp_to_asc4
> if we want to be completely correct.
And here is what I had in mind, checking the error code on top of the
output. The output is really optional, but that maps with 0 with the
offset applied, so I've just kept it.
--
Michael
Attachments:
0001-ecpg-Fix-out-of-bound-read-in-DecodeDateTime.patch (text/x-diff, 12.9K) download
From 97fd8f946e76a3bbe878bab4dfce8f64adfe35c6 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Tue, 22 Oct 2024 14:52:11 +0900
Subject: [PATCH] ecpg: Fix out-of-bound read in DecodeDateTime()
blah.
Backpatch-through: 12
---
src/interfaces/ecpg/pgtypeslib/dt_common.c | 6 +-
.../ecpg/test/expected/pgtypeslib-dt_test.c | 76 +++++++++++++------
.../test/expected/pgtypeslib-dt_test.stderr | 42 +++++-----
.../test/expected/pgtypeslib-dt_test.stdout | 3 +-
.../ecpg/test/pgtypeslib/dt_test.pgc | 30 ++++++++
5 files changed, 109 insertions(+), 48 deletions(-)
diff --git a/src/interfaces/ecpg/pgtypeslib/dt_common.c b/src/interfaces/ecpg/pgtypeslib/dt_common.c
index 0d63fe52c5..c4119ab793 100644
--- a/src/interfaces/ecpg/pgtypeslib/dt_common.c
+++ b/src/interfaces/ecpg/pgtypeslib/dt_common.c
@@ -2327,10 +2327,10 @@ DecodeDateTime(char **field, int *ftype, int nf,
return ((fmask & DTK_TIME_M) == DTK_TIME_M) ? 1 : -1;
/*
- * check for valid day of month, now that we know for sure the month
- * and year...
+ * check for valid day of month and month, now that we know for sure
+ * the month and year...
*/
- if (tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
+ if (tm->tm_mon < 1 || tm->tm_mday < 1 || tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1])
return -1;
/*
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
index ee867b6dd8..ae27b0d433 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
@@ -11,6 +11,7 @@
#include <string.h>
#include <stdlib.h>
#include <pgtypes_date.h>
+#include <pgtypes_error.h>
#include <pgtypes_timestamp.h>
#include <pgtypes_interval.h>
@@ -22,9 +23,11 @@
-#line 8 "dt_test.pgc"
+#line 9 "dt_test.pgc"
+static void check_errno(void);
+
int
main(void)
{
@@ -34,19 +37,19 @@ main(void)
-#line 14 "dt_test.pgc"
+#line 17 "dt_test.pgc"
date date1 ;
-#line 15 "dt_test.pgc"
+#line 18 "dt_test.pgc"
timestamp ts1 ;
-#line 16 "dt_test.pgc"
+#line 19 "dt_test.pgc"
interval * iv1 , iv2 ;
-#line 17 "dt_test.pgc"
+#line 20 "dt_test.pgc"
char * text ;
/* exec sql end declare section */
-#line 18 "dt_test.pgc"
+#line 21 "dt_test.pgc"
date date2;
int mdy[3] = { 4, 19, 1998 };
@@ -57,31 +60,31 @@ main(void)
ECPGdebug(1, stderr);
/* exec sql whenever sqlerror do sqlprint ( ) ; */
-#line 27 "dt_test.pgc"
+#line 30 "dt_test.pgc"
{ ECPGconnect(__LINE__, 0, "ecpg1_regression" , NULL, NULL , NULL, 0);
-#line 28 "dt_test.pgc"
+#line 31 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 28 "dt_test.pgc"
+#line 31 "dt_test.pgc"
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "create table date_test ( d date , ts timestamp )", ECPGt_EOIT, ECPGt_EORT);
-#line 29 "dt_test.pgc"
+#line 32 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 29 "dt_test.pgc"
+#line 32 "dt_test.pgc"
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "set datestyle to iso", ECPGt_EOIT, ECPGt_EORT);
-#line 30 "dt_test.pgc"
+#line 33 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 30 "dt_test.pgc"
+#line 33 "dt_test.pgc"
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "set intervalstyle to postgres_verbose", ECPGt_EOIT, ECPGt_EORT);
-#line 31 "dt_test.pgc"
+#line 34 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 31 "dt_test.pgc"
+#line 34 "dt_test.pgc"
date1 = PGTYPESdate_from_asc(d1, NULL);
@@ -92,10 +95,10 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_timestamp,&(ts1),(long)1,(long)1,sizeof(timestamp),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);
-#line 36 "dt_test.pgc"
+#line 39 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 36 "dt_test.pgc"
+#line 39 "dt_test.pgc"
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "select * from date_test where d = $1 ",
@@ -105,10 +108,10 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_timestamp,&(ts1),(long)1,(long)1,sizeof(timestamp),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
-#line 38 "dt_test.pgc"
+#line 41 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 38 "dt_test.pgc"
+#line 41 "dt_test.pgc"
text = PGTYPESdate_to_asc(date1);
@@ -263,10 +266,19 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
PGTYPESchar_free(text);
ts1 = PGTYPEStimestamp_from_asc("1994-02-11 26:10:35", NULL);
+ /* failure, check error code */
+ check_errno();
text = PGTYPEStimestamp_to_asc(ts1);
printf("timestamp_to_asc3: %s\n", text);
PGTYPESchar_free(text);
+ ts1 = PGTYPEStimestamp_from_asc("AM95000062", NULL);
+ /* failure, check error code */
+ check_errno();
+ text = PGTYPEStimestamp_to_asc(ts1);
+ printf("timestamp_to_asc4: %s\n", text);
+ PGTYPESchar_free(text);
+
/* abc-03:10:35-def-02/11/94-gh */
/* 12345678901234567890123456789 */
@@ -453,17 +465,35 @@ if (sqlca.sqlcode < 0) sqlprint ( );}
free(out);
{ ECPGtrans(__LINE__, NULL, "rollback");
-#line 381 "dt_test.pgc"
+#line 393 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 381 "dt_test.pgc"
+#line 393 "dt_test.pgc"
{ ECPGdisconnect(__LINE__, "CURRENT");
-#line 382 "dt_test.pgc"
+#line 394 "dt_test.pgc"
if (sqlca.sqlcode < 0) sqlprint ( );}
-#line 382 "dt_test.pgc"
+#line 394 "dt_test.pgc"
return 0;
}
+
+static void
+check_errno(void)
+{
+ switch(errno)
+ {
+ case 0:
+ printf("(no errno set) - ");
+ break;
+ case PGTYPES_TS_BAD_TIMESTAMP:
+ printf("(errno == PGTYPES_TS_BAD_TIMESTAMP) - ");
+ break;
+ default:
+ printf("(unknown errno (%d))\n", errno);
+ printf("(libc: (%s)) ", strerror(errno));
+ break;
+ }
+}
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
index 6e9ed3d3db..2a109ee7fa 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
@@ -2,47 +2,47 @@
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGconnect: opening database ecpg1_regression on <DEFAULT> port <DEFAULT>
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 29: query: create table date_test ( d date , ts timestamp ); with 0 parameter(s) on connection ecpg1_regression
+[NO_PID]: ecpg_execute on line 32: query: create table date_test ( d date , ts timestamp ); with 0 parameter(s) on connection ecpg1_regression
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 29: using PQexec
+[NO_PID]: ecpg_execute on line 32: using PQexec
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_process_output on line 29: OK: CREATE TABLE
+[NO_PID]: ecpg_process_output on line 32: OK: CREATE TABLE
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 30: query: set datestyle to iso; with 0 parameter(s) on connection ecpg1_regression
+[NO_PID]: ecpg_execute on line 33: query: set datestyle to iso; with 0 parameter(s) on connection ecpg1_regression
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 30: using PQexec
+[NO_PID]: ecpg_execute on line 33: using PQexec
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_process_output on line 30: OK: SET
+[NO_PID]: ecpg_process_output on line 33: OK: SET
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 31: query: set intervalstyle to postgres_verbose; with 0 parameter(s) on connection ecpg1_regression
+[NO_PID]: ecpg_execute on line 34: query: set intervalstyle to postgres_verbose; with 0 parameter(s) on connection ecpg1_regression
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 31: using PQexec
+[NO_PID]: ecpg_execute on line 34: using PQexec
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_process_output on line 31: OK: SET
+[NO_PID]: ecpg_process_output on line 34: OK: SET
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 36: query: insert into date_test ( d , ts ) values ( $1 , $2 ); with 2 parameter(s) on connection ecpg1_regression
+[NO_PID]: ecpg_execute on line 39: query: insert into date_test ( d , ts ) values ( $1 , $2 ); with 2 parameter(s) on connection ecpg1_regression
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 36: using PQexecParams
+[NO_PID]: ecpg_execute on line 39: using PQexecParams
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_free_params on line 36: parameter 1 = 1966-01-17
+[NO_PID]: ecpg_free_params on line 39: parameter 1 = 1966-01-17
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_free_params on line 36: parameter 2 = 2000-07-12 17:34:29
+[NO_PID]: ecpg_free_params on line 39: parameter 2 = 2000-07-12 17:34:29
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_process_output on line 36: OK: INSERT 0 1
+[NO_PID]: ecpg_process_output on line 39: OK: INSERT 0 1
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 38: query: select * from date_test where d = $1 ; with 1 parameter(s) on connection ecpg1_regression
+[NO_PID]: ecpg_execute on line 41: query: select * from date_test where d = $1 ; with 1 parameter(s) on connection ecpg1_regression
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_execute on line 38: using PQexecParams
+[NO_PID]: ecpg_execute on line 41: using PQexecParams
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_free_params on line 38: parameter 1 = 1966-01-17
+[NO_PID]: ecpg_free_params on line 41: parameter 1 = 1966-01-17
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_process_output on line 38: correctly got 1 tuples with 2 fields
+[NO_PID]: ecpg_process_output on line 41: correctly got 1 tuples with 2 fields
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_get_data on line 38: RESULT: 1966-01-17 offset: -1; array: no
+[NO_PID]: ecpg_get_data on line 41: RESULT: 1966-01-17 offset: -1; array: no
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ecpg_get_data on line 38: RESULT: 2000-07-12 17:34:29 offset: -1; array: no
+[NO_PID]: ecpg_get_data on line 41: RESULT: 2000-07-12 17:34:29 offset: -1; array: no
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ECPGtrans on line 381: action "rollback"; connection "ecpg1_regression"
+[NO_PID]: ECPGtrans on line 393: action "rollback"; connection "ecpg1_regression"
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ecpg_finish: connection ecpg1_regression closed
[NO_PID]: sqlca: code: 0, state: 00000
diff --git a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
index 4b582fd7a2..6b8bcc9fc2 100644
--- a/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
+++ b/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
@@ -20,7 +20,8 @@ date_defmt_asc10: 1995-12-25
date_defmt_asc12: 0095-12-25
timestamp_to_asc1: 1996-02-29 00:00:00
timestamp_to_asc2: 1994-02-11 03:10:35
-timestamp_to_asc3: 2000-01-01 00:00:00
+(errno == PGTYPES_TS_BAD_TIMESTAMP) - timestamp_to_asc3: 2000-01-01 00:00:00
+(errno == PGTYPES_TS_BAD_TIMESTAMP) - timestamp_to_asc4: 2000-01-01 00:00:00
timestamp_fmt_asc: 0: abc-00:00:00-def-01/01/00-ghi%
timestamp_defmt_asc(This is a 4/12/80 3-39l12test, This is a %m/%d/%y %H-%Ml%Stest) = 1980-04-12 03:39:12, error: 0
timestamp_defmt_asc(Tue Jul 22 17:28:44 +0200 2003, %a %b %d %H:%M:%S %z %Y) = 2003-07-22 15:28:44, error: 0
diff --git a/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc b/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
index f81a392665..b34e1d2f06 100644
--- a/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
+++ b/src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
@@ -2,11 +2,14 @@
#include <string.h>
#include <stdlib.h>
#include <pgtypes_date.h>
+#include <pgtypes_error.h>
#include <pgtypes_timestamp.h>
#include <pgtypes_interval.h>
exec sql include ../regression;
+static void check_errno(void);
+
int
main(void)
{
@@ -189,10 +192,19 @@ main(void)
PGTYPESchar_free(text);
ts1 = PGTYPEStimestamp_from_asc("1994-02-11 26:10:35", NULL);
+ /* failure, check error code */
+ check_errno();
text = PGTYPEStimestamp_to_asc(ts1);
printf("timestamp_to_asc3: %s\n", text);
PGTYPESchar_free(text);
+ ts1 = PGTYPEStimestamp_from_asc("AM95000062", NULL);
+ /* failure, check error code */
+ check_errno();
+ text = PGTYPEStimestamp_to_asc(ts1);
+ printf("timestamp_to_asc4: %s\n", text);
+ PGTYPESchar_free(text);
+
/* abc-03:10:35-def-02/11/94-gh */
/* 12345678901234567890123456789 */
@@ -383,3 +395,21 @@ main(void)
return 0;
}
+
+static void
+check_errno(void)
+{
+ switch(errno)
+ {
+ case 0:
+ printf("(no errno set) - ");
+ break;
+ case PGTYPES_TS_BAD_TIMESTAMP:
+ printf("(errno == PGTYPES_TS_BAD_TIMESTAMP) - ");
+ break;
+ default:
+ printf("(unknown errno (%d))\n", errno);
+ printf("(libc: (%s)) ", strerror(errno));
+ break;
+ }
+}
--
2.45.2
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-22 23:37 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2024-10-22 23:37 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: p.nekrasov@fobos-nt.ru; pgsql-bugs@lists.postgresql.org
On Tue, Oct 22, 2024 at 02:53:50PM +0900, Michael Paquier wrote:
> And here is what I had in mind, checking the error code on top of the
> output. The output is really optional, but that maps with 0 with the
> offset applied, so I've just kept it.
I had some time this morning, so I have looked at it again, kept the
patch as-is, and backpatched all the way down (with proper authorship
of course).
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-24 09:09 Павел Некрасов <p.nekrasov@fobos-nt.ru>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 12+ messages in thread
From: Павел Некрасов @ 2024-10-24 09:09 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-bugs@lists.postgresql.org
Hello,
I would like to clarify two points:
1. Are there any known examples of large open-source projects that actively use the ecpg?
2. Do you think it would be appropriate to assign a CVE for this bug?
Best regards,
Pavel Nekrasov
Fobos-NT
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-24 22:25 Michael Paquier <michael@paquier.xyz>
parent: Павел Некрасов <p.nekrasov@fobos-nt.ru>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2024-10-24 22:25 UTC (permalink / raw)
To: Павел Некрасов <p.nekrasov@fobos-nt.ru>; +Cc: Bruce Momjian <bruce@momjian.us>; pgsql-bugs@lists.postgresql.org
On Thu, Oct 24, 2024 at 12:09:10PM +0300, Павел Некрасов wrote:
> I would like to clarify two points:
>
> 1. Are there any known examples of large open-source projects that
> actively use the ecpg?
Yes, some large organizations use it.
> 2. Do you think it would be appropriate to assign a CVE for this bug?
Nope, this issue does not qualify as worth a CVE when it comes to
PostgreSQL.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-25 06:23 Павел Некрасов <p.nekrasov@fobos-nt.ru>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 2 replies; 12+ messages in thread
From: Павел Некрасов @ 2024-10-25 06:23 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Thank you for the clarification!
Would it be possible to know which specific organizations or projects actively use ecpg?
Best regards,
Pavel Nekrasov
Fobos-NT
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-25 09:39 Matthias Apitz <guru@unixarea.de>
parent: Павел Некрасов <p.nekrasov@fobos-nt.ru>
1 sibling, 0 replies; 12+ messages in thread
From: Matthias Apitz @ 2024-10-25 09:39 UTC (permalink / raw)
To: Павел Некрасов <p.nekrasov@fobos-nt.ru>; +Cc: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; pgsql-bugs <pgsql-bugs@lists.postgresql.org>
El día viernes, octubre 25, 2024 a las 09:23:17 +0300, Павел Некрасов escribió:
> Thank you for the clarification!
>
> Would it be possible to know which specific organizations or projects actively use ecpg?
>
> Best regards,
> Pavel Nekrasov
> Fobos-NT
Our software, a complete Library Management System, uses ECPG from C and
C++ written servers on Linux.
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)
I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18614: [ECPG] out of bound in DecodeDateTime
@ 2024-10-26 14:14 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Павел Некрасов <p.nekrasov@fobos-nt.ru>
1 sibling, 0 replies; 12+ messages in thread
From: Alvaro Herrera @ 2024-10-26 14:14 UTC (permalink / raw)
To: Павел Некрасов <p.nekrasov@fobos-nt.ru>; +Cc: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; pgsql-bugs <pgsql-bugs@lists.postgresql.org>
On 2024-Oct-25, Павел Некрасов wrote:
> Thank you for the clarification!
>
> Would it be possible to know which specific organizations or projects
> actively use ecpg?
It doesn't seem realistic to maintain a complete list, and many
organizations are just not going to tell us or anyone that they're using
it.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"This is a foot just waiting to be shot" (Andrew Dunstan)
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2024-10-26 14:14 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-12 08:54 BUG #18614: [ECPG] out of bound in DecodeDateTime PG Bug reporting form <noreply@postgresql.org>
2024-10-14 21:52 ` Bruce Momjian <bruce@momjian.us>
2024-10-16 00:18 ` Michael Paquier <michael@paquier.xyz>
2024-10-17 17:29 ` Bruce Momjian <bruce@momjian.us>
2024-10-18 05:51 ` Michael Paquier <michael@paquier.xyz>
2024-10-22 05:53 ` Michael Paquier <michael@paquier.xyz>
2024-10-22 23:37 ` Michael Paquier <michael@paquier.xyz>
2024-10-24 09:09 ` Павел Некрасов <p.nekrasov@fobos-nt.ru>
2024-10-24 22:25 ` Michael Paquier <michael@paquier.xyz>
2024-10-25 06:23 ` Павел Некрасов <p.nekrasov@fobos-nt.ru>
2024-10-25 09:39 ` Matthias Apitz <guru@unixarea.de>
2024-10-26 14:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
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