| From: | Markus Wanner <markus(dot)wanner(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Markus Wanner <markus(dot)wanner(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: invalid alloc size error possible in shm_mq |
| Date: | 2020-09-09 12:37:17 |
| Message-ID: | d0761291-3ac5-3b3c-c6cd-0f89be3de2b9@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 8/25/20 12:00 PM, Peter Eisentraut wrote:
> I wonder if the assertion is appropriate or whether it should be a full
> error check.
Good point. Originally, it used to be an error. With the patch (but
w/o assertions enabled) it could result in a buffer overrun. Not good.
I changed the patch to add an error (instead of just an assert) when
asked to read a message larger than MaxAllocSize. So this patch
essentially corrects handling of messages in size between MaxAllocSize/2
and MaxAllocSize.
> Is anything on the sending side ensuring that the maximum
> size is kept? All the size variables are Size/size_t so could be much
> larger than MaxAllocSize.
In this v2 of the patch, I added a check that errors out on the sender
side as well (for trying to send a message larger than MaxAllocSize).
I'd still recommend to back-patch this.
--
Markus Wanner
Senior PostgreSQL Developer
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
| Attachment | Content-Type | Size |
|---|---|---|
| shm_mq_inv_allocation_fix_v2.diff | text/x-patch | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-09-09 12:46:34 | Re: BUG #16577: Segfault on altering a table located in a dropped tablespace |
| Previous Message | Jehan-Guillaume de Rorthais | 2020-09-09 10:58:40 | Re: [BUG v13] Crash with event trigger in extension |