agora inbox for pgpool-hackers@postgresql.org
help / color / mirror / Atom feed[PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
322+ messages / 1 participants
[nested] [flat]
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 05:44 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 05:44 UTC (permalink / raw)
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Reported-by: Emond Papegaaij <emond.papegaaij@gmail.com>
Reported-by: Claude code
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion:
Backpatch-through: v4.3
---
src/protocol/pool_process_query.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/protocol/pool_process_query.c b/src/protocol/pool_process_query.c
index a2fea2640..202afa2a3 100644
--- a/src/protocol/pool_process_query.c
+++ b/src/protocol/pool_process_query.c
@@ -3569,6 +3569,10 @@ read_kind_from_backend(POOL_CONNECTION *frontend, POOL_CONNECTION_POOL *backend,
if (major == PROTO_MAJOR_V3)
{
pool_read(CONNECTION(backend, i), &len, sizeof(len));
+ if (ntohl(len) < sizeof(len))
+ ereport(ERROR,
+ (errmsg("read_kind_from_backend: ErrorResponse length %u is below the %zu-byte minimum",
+ ntohl(len), sizeof(len))));
unread_len = sizeof(len);
unread_p = palloc(ntohl(len));
memcpy(unread_p, &len, sizeof(len));
--
2.43.0
----Next_Part(Fri_Jun_26_15_32_27_2026_961)----
^ permalink raw reply [nested|flat] 322+ messages in thread
* Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-06-26 06:32 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 322+ messages in thread
From: Tatsuo Ishii @ 2026-06-26 06:32 UTC (permalink / raw)
To: pgpool-hackers@lists.postgresql.org
Emond Papegaaij reported a bug in read_kind_from_backend.
read_kind_from_backend() handles a backend ErrorResponse on the V3
path by reading the 4-byte length field, palloc'ing a buffer sized at
ntohl(len), and immediately memcpy()ing all 4 bytes of the
network-order length back into that buffer. When a backend (malicious,
buggy, or speaking a non-V3 dialect that has slipped past earlier
checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
chunk is smaller than sizeof(len) and the memcpy overruns the heap
allocation. The follow-up `len -= 4` then underflows to a huge
unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
len)` may wrap, and pool_read2() is asked for a colossal payload ―
all on top of an already-corrupted heap.
Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
...). The error path is the existing longjmp-based one used by every
other malformed-input check in this function, so the connection is
torn down cleanly without touching unread_p.
Patch attached.
Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Attachments:
[text/x-patch] v1-0001-Reject-sub-minimum-ErrorResponse-length-in-read_k.patch (0B, ../../20260626.153227.1428186004607098961.ishii@postgresql.org/2-v1-0001-Reject-sub-minimum-ErrorResponse-length-in-read_k.patch)
download
^ permalink raw reply [nested|flat] 322+ messages in thread
* Re: Reject sub-minimum ErrorResponse length in read_kind_from_backend.
@ 2026-07-07 22:19 Tatsuo Ishii <ishii@postgresql.org>
parent: Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 322+ messages in thread
From: Tatsuo Ishii @ 2026-07-07 22:19 UTC (permalink / raw)
To: pgpool-hackers@lists.postgresql.org; +Cc: Emond Papegaaij <emond.papegaaij@gmail.com>
> Emond Papegaaij reported a bug in read_kind_from_backend.
>
> read_kind_from_backend() handles a backend ErrorResponse on the V3
> path by reading the 4-byte length field, palloc'ing a buffer sized at
> ntohl(len), and immediately memcpy()ing all 4 bytes of the
> network-order length back into that buffer. When a backend (malicious,
> buggy, or speaking a non-V3 dialect that has slipped past earlier
> checks) sends a length below 4 ― i.e. in {0,1,2,3} ― the palloc
> chunk is smaller than sizeof(len) and the memcpy overruns the heap
> allocation. The follow-up `len -= 4` then underflows to a huge
> unsigned value, which the subsequent `repalloc(unread_p, sizeof(len) +
> len)` may wrap, and pool_read2() is asked for a colossal payload ―
> all on top of an already-corrupted heap.
>
> Reject any ntohl(len) below sizeof(len) up front with ereport(ERROR,
> ...). The error path is the existing longjmp-based one used by every
> other malformed-input check in this function, so the connection is
> torn down cleanly without touching unread_p.
>
> Patch attached.
Peng and Koshino reviewed the patch off-list and they agreed that it
looks good. I have pushed the patch to all supported branches.
Thank you, Emond.
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=912d7ce0b9d3a29a343a4b828e86fc05c0f47755
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 322+ messages in thread
end of thread, other threads:[~2026-07-07 22:19 UTC | newest]
Thread overview: 322+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 05:44 [PATCH v1] Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-06-26 06:32 Reject sub-minimum ErrorResponse length in read_kind_from_backend. Tatsuo Ishii <ishii@postgresql.org>
2026-07-07 22:19 ` Tatsuo Ishii <ishii@postgresql.org>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox