Re: doPickSplit stack buffer overflow in XLogInsert?
| От | Peter Geoghegan |
|---|---|
| Тема | Re: doPickSplit stack buffer overflow in XLogInsert? |
| Дата | |
| Msg-id | CAM3SWZTrzmgyXLJrVHVbD8bSSY4zNS3xyDwmtmJ3ctc9py7qAg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: doPickSplit stack buffer overflow in XLogInsert? (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: doPickSplit stack buffer overflow in XLogInsert?
Re: doPickSplit stack buffer overflow in XLogInsert? |
| Список | pgsql-hackers |
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch <noah@leadboat.com> wrote: > The threat is that rounding the read size up to the next MAXALIGN would cross > into an unreadable memory page, resulting in a SIGSEGV. Every palloc chunk > has MAXALIGN'd size under the hood, so the excess read of "toDelete" cannot > cause a SIGSEGV. For a stack variable, it depends on the ABI. I'm not aware > of an ABI where the four bytes past the end of this stack variable could be > unreadable, which is not to claim I'm well-read on the topic. We should fix > this in due course on code hygiene grounds, but I would not back-patch it. Attached patch silences the "Invalid read of size n" complaints of Valgrind. I agree with your general thoughts around backpatching. Note that the patch addresses a distinct complaint from Kevin's, as Valgrind doesn't take issue with the invalid reads past the end of spgxlogPickSplit variables on the stack. -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: