Date: Tue, 3 Dec 2019 18:52:11 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: cilizili@protonmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16144: Segmentation fault on dict_int extension
Message-ID: <20191203175211.fllaggkccolrngbi@development>
References: <16144-a36a5bef7657047d@postgresql.org>
 <20191202161920.d3k7b6dpqcgl5mst@development>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20191202161920.d3k7b6dpqcgl5mst@development>
Precedence: bulk

On Mon, Dec 02, 2019 at 05:19:20PM +0100, Tomas Vondra wrote:
>On Mon, Dec 02, 2019 at 12:41:21PM +0000, PG Bug reporting form wrote:
>>The following bug has been logged on the website:
>>
>>Bug reference:      16144
>>Logged by:          cili
>>Email address:      cilizili@protonmail.com
>>PostgreSQL version: 12.1
>>Operating system:   CentOS 7.4
>>Description:
>>
>>The dict_int extension is an example of an add-on dictionary template for
>>full-text search. The 'intdict' is a built-in dictionary. If we set MAXLEN
>>parameter with negative value for the dictionary, ts_lexize function causes
>>a segmentation fault. The negative limit for MAXLEN which causes
>>segmentation fault is environment dependent.
>>
>># initdb
>># pg_ctl -D /var/lib/pgsql/data -l logfile start
>># psql
>>
>>postgres=# CREATE EXTENSION dict_int;
>>CREATE EXTENSION
>>postgres=# ALTER TEXT SEARCH DICTIONARY intdict (MAXLEN = -214783648);
>>ALTER TEXT SEARCH DICTIONARY
>>postgres=# select ts_lexize('intdict', '12345678');
>>server closed the connection unexpectedly
>>	This probably means the server terminated abnormally
>>	before or while processing the request.
>>The connection to the server was lost. Attempting reset: Failed.
>>!>
>>!>\q
>>
>
>Yeah, this seems to be a failure in evaluating maxlen parameter. It's
>set to 6 by default, but we simply trust whatever value the user gives
>us, and then we do this
>
>    txt[d->maxlen] = '\0';
>
>which fails for obvious reasons.
>
>Will fix by rejecting maxlen values less than 1. The docs don't say
>which value should the the minimum, but 0 seems useless.
>

I've pushed a fix for this, rejecting maxlen values less than 1. I also
backpatched this to all supported releases (the issue exists since 9.3).

As for the upper limit, that's capped by length of the input string.
There's an issue with using atoi() which does not report errors, but
that's a separate issue.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services