From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: tvijlbrief@gmail.com, pgsql-bugs@lists.postgresql.org, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring
Date: Mon, 02 Nov 2020 00:16:45 -0500
Message-ID: <592336.1604294205@sss.pgh.pa.us> (raw)
In-Reply-To: <A0C09497-3C7B-44E5-9224-CE86F7E87DBE@yandex-team.ru>
References: <16694-f107871e499ec114@postgresql.org>
<543595.1604267856@sss.pgh.pa.us>
<578150.1604274357@sss.pgh.pa.us>
<A0C09497-3C7B-44E5-9224-CE86F7E87DBE@yandex-team.ru>
Andrey Borodin <x4mmm@yandex-team.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 don't buy the "security" aspect,
since there's no plausible route for an attacker to inject corrupted
compressed data unless they already have full access to the database.
The "maybe core dump" argument is a bit stronger, but not very much so.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, x4mmm@yandex-team.ru, tomas.vondra@2ndquadrant.com
Subject: Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring
In-Reply-To: <592336.1604294205@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox