Buffer overflow in SerializeLibraryState() found by Address Sanitizer
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51725psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 03:27 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51725_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51725_1 && git checkout t51725_1Patchset v1 (message #1) is on t51725_1
Hi hackers!
SerializeLibraryState() writes 1 byte too much into the buffer pointed
to by start_address. This is the very last '\0' it writes after the
loop. Attached is a patch that fixes the problem by accounting for that
extra byte in EstimateLibraryStateSpace()
--
David Geier
(ServiceNow)
On 10 Jun 2025, at 14:59, David Geier <geidav.pg@gmail.com> wrote:
Hi hackers!
SerializeLibraryState() writes 1 byte too much into the buffer pointed to by start_address. This is the very last '\0' it writes after the loop. Attached is a patch that fixes the problem by accounting for that extra byte in EstimateLibraryStateSpace()
The last '\0' written isn't performed in relation to the size, but at a fixed
index in the buffer:
...
}
start_address[0] = '\0';
How would that cause a buffer overflow?
--
Daniel Gustafsson
The loop advances the pointer via start_address += len.
--
David Geier
(ServiceNow
On 6/10/2025 3:06 PM, Daniel Gustafsson wrote:
On 10 Jun 2025, at 14:59, David Geier <geidav.pg@gmail.com> wrote:
Hi hackers!
SerializeLibraryState() writes 1 byte too much into the buffer pointed to by start_address. This is the very last '\0' it writes after the loop. Attached is a patch that fixes the problem by accounting for that extra byte in EstimateLibraryStateSpace()
The last '\0' written isn't performed in relation to the size, but at a fixed
index in the buffer:...
}
start_address[0] = '\0';How would that cause a buffer overflow?
--
Daniel Gustafsson
--
David Geier
(ServiceNow)
But just seeing now that size in EstimateLibraryState() is initialized
to 1. So that total size should actually be fine. Weird that the patch
makes the sanitizer error disappear.
On 6/10/2025 4:21 PM, David Geier wrote:
The loop advances the pointer via start_address += len.
--
David Geier
(ServiceNow)