Re: Hunspell AF alias count silently wraps to a smaller value

чт, 10 сент. 2026 г. в 17:08, ♂π≌26218 <1991230470(at)qq(dot)com>:

> Hi,
>
> I found a potential bug in PostgreSQL's Hunspell dictionary parser where an over-wide `AF` alias count in an affix file is accepted after being silently converted to a smaller positive integer, without any error or warning.
>
> Description:
>
> An affix file declaring `AF 4294967297` (which exceeds the maximum value representable in a 32-bit unsigned integer by 1) but containing only one alias definition loads successfully and behaves as if it declared one alias. The parsing path appears to use a narrow integer conversion and validates only the converted value, not whether the original number can be represented without loss.
>
> PostgreSQL version:
> - PostgreSQL 19beta3 (Docker-based runtime)
> - Source commit: not recorded in the original report
> - Build relationship: the tested image was not an exact-HEAD build
>
> Environment:
> - Docker-based PostgreSQL 19beta3 runtime
> - Hunspell dictionary support enabled by default
> - No special server configuration required beyond superuser access to create dictionaries
>
> Steps to Reproduce:
>
> Create `af_overflow.affix` in PostgreSQL's `tsearch_data` directory:
>
> ```text
> SET UTF-8
> AF 4294967297
> AF A
> PFX A Y 1
> PFX A 0 re .
>
> Create af_overflow.dict:
> text
>
> book/1
>
> Then, as a superuser, execute the following SQL:
> sql
>
> \set VERBOSITY verboseCREATE TEXT SEARCH DICTIONARY af_overflow (
> TEMPLATE = ispell,
> DictFile = af_overflow,
> AffFile = af_overflow);SELECT ts_lexize('af_overflow', 'rebook');
>
> Actual Result:
>
> The dictionary is created successfully without any error. ts_lexize
> returns:
> text
>
> {book}
>
> The declared value 4294967297 effectively behaves as if the alias count
> was 1, which matches the number of defined aliases.
>
> Expected Result:
>
> The loader should reject an AF count that is out of range, cannot be
> converted losslessly, or does not match the number of alias definitions. An
> explicit error message such as "AF alias count out of range" or "number of
> AF aliases does not match declaration" would be appropriate.
>
> Reproduction Frequency:
>
> -
>
> Positive reproduction: 2/2 on PostgreSQL 19beta3
> -
>
> Negative control: replacing the count with AF 1 loads and lexizes
> normally
>
> Additional Observations:
>
> This appears to be a low-impact issue because it requires elevated
> privileges to install dictionary files and create text-search dictionaries.
> However, it could lead to subtle misbehavior if a dictionary file with an
> overflowed count is accidentally used. The issue is likely located in the
> affix-file parsing code where the AF count is converted without checking
> for overflow or loss of precision.
>
> I searched the public PostgreSQL bug archives and did not find any report
> specifically addressing overflow handling of AF alias counts. Please
> confirm whether this is considered a bug or an intentional limitation of
> the parsing logic.
>
> ♂π≌26218
> 1991230470(at)qq(dot)com
>
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=%E2%99%82%CF%80%E2%89%8C26218&icon=https%3A%2F%2Fp.qlogo.cn%2Fqqmail_head%2F7zCZdnCEqwFr60hzEibU1KOjLPppnhmolM05y60o9OJhh4GoeKYHtrSgNUk8KpD2I%2F160&mail=1991230470%40qq.com&code=g5VzPQl67UBOaO3N0VLdCtumeljBoBFYOGmy5Le_CPM8hp3rB1CbWb9Mf7UfBsq8Ecxg9ZBK8rZhZfvlSXXlwg>
>

Hi!

Thnx for the report.

Proposal Fix
-----------------
Parse the count with strtol(), same pattern as parseNumericAffixFlag().
Reject ERANGE, non-numeric input, n <= 0, and n >= INT_MAX (room is
needed for the empty flag-set slot).

--
Regards,
Rachitskiy Andrey