Horton

Thread

Commits

  1. Ensure maxlen is at leat 1 in dict_int

  1. BUG #16144: Segmentation fault on dict_int extension

    The Post Office <noreply@postgresql.org> — 2019-12-02T12:41:21Z

    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

# cat /var/lib/pgsql/data/pg_log/postgresql-Mon.log
LOG:  database system was shut down at 2019-12-02 12:05:17 UTC
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  server process (PID 5288) was terminated by signal 11: Segmentation
fault
DETAIL:  Failed process was running: select ts_lexize('intdict',
'12345678');
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server
process
DETAIL:  The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
LOG:  all server processes terminated; reinitializing
FATAL:  the database system is in recovery mode
LOG:  database system was interrupted; last known up at 2019-12-02 12:05:24
UTC
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  redo starts at 0/180D7F8
LOG:  record with zero length at 0/1822720
LOG:  redo done at 0/18226F0
LOG:  last completed transaction was at log time 2019-12-02
12:05:42.199372+00
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

  2. Re: BUG #16144: Segmentation fault on dict_int extension

    Tomas Vondra <tomas.vondra@2ndquadrant.com> — 2019-12-02T16:19:20Z

    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.


regards

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

  3. Re: BUG #16144: Segmentation fault on dict_int extension

    Tomas Vondra <tomas.vondra@2ndquadrant.com> — 2019-12-03T17:52:11Z

    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

  4. Re: BUG #16144: Segmentation fault on dict_int extension

    Tomas Vondra <tomas.vondra@2ndquadrant.com> — 2019-12-03T18:06:53Z

    On Tue, Dec 03, 2019 at 06:52:11PM +0100, Tomas Vondra wrote:
>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).
>

Damn, a silly typo in the commit subject (leat -> least) ... :-/

regards

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