BUG #16144: Segmentation fault on dict_int extension

Started by PG Bug reporting formover 6 years ago4 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

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

#2Tomas Vondra
tomas.vondra@2ndquadrant.com
In reply to: PG Bug reporting form (#1)
Re: BUG #16144: Segmentation fault on dict_int extension

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

#3Tomas Vondra
tomas.vondra@2ndquadrant.com
In reply to: Tomas Vondra (#2)
Re: BUG #16144: Segmentation fault on dict_int extension

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

#4Tomas Vondra
tomas.vondra@2ndquadrant.com
In reply to: Tomas Vondra (#3)
Re: BUG #16144: Segmentation fault on dict_int extension

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