| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | tvijlbrief(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Subject: | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |
| Date: | 2020-11-02 05:33:09 |
| Message-ID: | 727877DF-78F7-4C1E-B1A5-C0A97BF276CE@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 2 нояб. 2020 г., в 10:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>
> Andrey Borodin <x4mmm(at)yandex-team(dot)ru> writes:
>> I'm not sure protection from corrupt input is complete within pglz. We
>> still do not protect from matches with offsets before source data.
>
> Yeah, I was wondering about that. Not quite sure it's worth adding
> cycles to defend against though.
I think so too. That's why I was not protecting from corruption at all when proposing c60e520.
Here we can have core dump too if *(srcend+1) produce SegFault:
len = (sp[0] & 0x0f) + 3;
off = ((sp[0] & 0xf0) << 4) | sp[1];
sp += 2;
if (len == 18)
len += *sp++;
if (sp > srcend || off == 0)
break;
And proper protection would cost nonzero time for branches. I think we should not protect against this.
I hope to see lz4 (or something else) in toast and other places one day :)
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-11-02 05:53:48 | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |
| Previous Message | Tom Lane | 2020-11-02 05:16:45 | Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring |