| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | pgpool-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Reject sub-minimum ErrorResponse length in read_kind_from_backend. |
| Date: | 2026-06-26 06:32:27 |
| Message-ID: | 20260626.153227.1428186004607098961.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgpool-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Reject-sub-minimum-ErrorResponse-length-in-read_k.patch | text/x-patch | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nadav Shatz | 2026-06-26 10:25:05 | Re: Proposal: Recent mutated table tracking in memory |
| Previous Message | Tatsuo Ishii | 2026-06-25 22:40:28 | Re: Proposal: Recent mutated table tracking in memory |