Re: doPickSplit stack buffer overflow in XLogInsert?
| От | Kevin Grittner |
|---|---|
| Тема | Re: doPickSplit stack buffer overflow in XLogInsert? |
| Дата | |
| Msg-id | 1385581103.88569.YahooMailNeo@web162901.mail.bf1.yahoo.com обсуждение исходный текст |
| Ответ на | Re: doPickSplit stack buffer overflow in XLogInsert? (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: doPickSplit stack buffer overflow in XLogInsert?
|
| Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> wrote: > (Kevin, I saw no attachment.) Apologies. Trying again. > 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. If you're sure. I hadn't worked through the code, but had two concerns (neither of which was about a SEGSEGV): (1) That multiple MAXALIGNs of shorter values could push the structure into overlap with the next thing on the stack, allowing one or the other to get stepped on. (2) That the CRC calculation might picking up uninitialized data which was not actually going to match what was used during recovery, leading to "end of recovery" on replay. If you are confident that neither of these is a real risk, I'll relax about this. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: