| From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | dan-eli(at)mail(dot)ru |
| Subject: | BUG #18797: pointer te->defn not checked for NULL |
| Date: | 2025-02-06 11:28:22 |
| Message-ID: | 18797-e48e5e7be4954d72@postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 18797
Logged by: Daniel Elishakov
Email address: dan-eli(at)mail(dot)ru
PostgreSQL version: 16.6
Operating system: ubuntu 20.04
Description:
src/interfaces/ecpg/pgtypeslib/dt_common.c:2662
src/interfaces/ecpg/pgtypeslib/dt_common.c:2787
src/interfaces/ecpg/pgtypeslib/dt_common.c:2795
src/interfaces/ecpg/pgtypeslib/dt_common.c:2840
in function PGTYPEStimestamp_defmt_scan there is a usage of pgtypes_alloc().
In other functions the result of pgtypes_alloc is being checked for NULL.
For example, in /src/interfaces/ecpg/pgtypeslib/numeric.c. I think in
PGTYPEStimestamp_defmt_scan it is also worth checking for NULL before
dereferencing in strcpy, because PGTYPEStimestamp_defmt_scan is being called
recursively and if there won't be any available memory to allocate, it can
be a real problem in terms of data consistency.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2025-02-06 11:43:44 | BUG #18798: /src/interfaces/ecpg/preproc/type.c possible NULL deref |
| Previous Message | Pierre-Paul Hackens | 2025-02-06 10:10:43 | pg_get_constraintdef throws SQL Error [XX000]: ERROR: invalid constraint type "n" (PG17) |