Re: CREATE TEXT SEARCH DICTIONARY segfaulting on 9.6+

Hello Tomas,

On 2019/10/13 10:26, Tomas Vondra wrote:
> over in pgsql-bugs [1] we got a report about CREATE TEXT SEARCH
> DICTIONARY causing segfaults on 12.0. Simply running
>
>    CREATE TEXT SEARCH DICTIONARY hunspell_num (Template=ispell,
>    DictFile=hunspell_sample_num, AffFile=hunspell_sample_long);
>
> does trigger a crash, 100% of the time. The crash was reported on 12.0,
> but it's in fact present since 9.6.
>
> On 9.5 the example does not work, because that version does not (a)
> include the hunspell dictionaries used in the example, and (b) it does
> not support long flags. So even after copying the dictionaries and
> tweaking them a bit it still passes without a crash.

This crash is not because of long flags, but because of aliases (more
thoughts below).

> Looking at the commit history of spell.c, there seems to be a bunch of
> commits in 2016 (e.g. f4ceed6ceba3) touching exactly this part of the
> code (hunspell), and it also correlates quite nicely with the affected
> branches (9.6+). So my best guess is it's a bug in those changes.

Yeah, there was a lot changes.

> So it simply grabs whatever it finds in the dict file, parses it and
> then (later) we use it as index to access the AffixData array, even if
> the value is way out of bounds.

Yes, we enter this code if an affix file defines aliases (AF parameter).
AffixData array is used to store those aliases.

More about hunspell format you can find here:
https://linux.die.net/man/4/hunspell

In the example we have the following aliases:
AF 11
AF cZ #1
AF cL #2
...
AF sB #11

And in the dictionary file we should use their indexes (from 1 to 11).
These aliases defines set of flags and in the dict file we can use only
single index:
book/3
book/11

but not:
book/3,4
book/2,11

I added checking of this last case in the attached patch. PostgreSQL
will raise an error if it sees non-numeric and non-whitespace character
after the index.

Aliases can be used with all flag types: 'default' (i.e. FM_CHAR),
'long', and if I'm not mistaken 'num'.

> So I think we need some sort of cross-check here. We certainly need to
> make NISortDictionary() check the affix value is within AffixData
> bounds, and error out when the index is non-sensical (maybe negative
> and/or exceeding nAffixData).

I agree, I attached the patch which do this. I also added couple
asserts, tests and fixed condition in getAffixFlagSet():

- if (curaffix > 0 && curaffix <= Conf->nAffixData)
+ if (curaffix > 0 && curaffix < Conf->nAffixData)

I think it could be a bug, because curaffix can't be equal to
Conf->nAffixData.

> Maybe there's a simple way to check if the affix/dict files match.

I'm not sure how to properly fix this either. The only thing we could
check is commas in affix flags in a dict file:

book/302,301,202,303

FM_CHAR and FM_LONG dictionaries can't have commas. They should have the
following affix flags:

book/sGsJpUsS # 4 affixes for FM_LONG
book/GJUS # 4 affixes for FM_CHAR

But I guess they could have numbers in flags (as help says "Set flag
type. Default type is the extended ASCII (8-bit) character.") and other
non alphanumeric characters (as some language dictionaries have):

book/s1s2s3s4 # 4 affixes for FM_LONG

--
Artur