[PATCH] Fix heap-buffer-overflow in PGTYPEStimestamp_defmt_scan()

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

Responses

Browse pgsql-hackers by date

  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