| From: | Sivirilova Marija <m(dot)sivirilova(at)ftdata(dot)ru> |
|---|---|
| To: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | [PATCH] Fix heap-buffer-overflow in PGTYPEStimestamp_defmt_scan() |
| Date: | 2026-08-19 06:55:53 |
| Message-ID: | e3a21340a7844ada81c38aa5a164c58b@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello, hackers!
We used the Clang Static Analyzer and found a heap-buffer-overflow in the PGTYPEStimestamp_defmt_scan() function inside src/interfaces/ecpg/pgtypeslib/dt_common.c. When processing template tokens like '%D', '%r', '%R', or '%T', the code allocates a temporary buffer based on the length of the remaining input string (pstr). However, it later concatenates the remaining format string (pfmt) into this buffer using strcat(). If an application attempts to parse a short or truncated time string using a longer, complex format pattern, the format string suffix will exceed the allocated memory, causing a heap-buffer-overflow.
The issue can be reproduced with a minimal test case (compiling this with AddressSanitizer):
timestamp ts;
PGTYPEStimestamp_defmt_asc("1", "%D %H:%M:%S", &ts);
ERROR: AddressSanitizer: heap-buffer-overflow WRITE of size 10 at 0x... 0 bytes after 10-byte region
#0 strcat
#1 PGTYPEStimestamp_defmt_scan dt_common.c:2667
#2 PGTYPEStimestamp_defmt_asc timestamp.c:841 allocated by pgtypes_alloc common.c:12
The solution is to allocate memory based on the length of the format string (pfmt) instead of the input string (pstr), as it is the string being appended.
Best regards,
Maria Sivirilova
Kanatbek Kanybekov
| Attachment | Content-Type | Size |
|---|---|---|
| Fix-heap-buffer-overflow.patch | application/octet-stream | 2.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ZizhuanLiu X-MAN | 2026-08-19 06:59:16 | Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match |
| Previous Message | Richard Guo | 2026-08-19 06:53:46 | Re: Reduce LEFT/FULL JOIN to ANTI JOIN in more cases |