agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Prevent some buffer overruns in spell.c's parsing of affix files 6+ messages / 1 participants [nested] [flat]
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d7970e7e951bb39b0d5d7ae633fc7f1af54aa932 Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/00c6e08195d5b14bd022644dba64698c2640a8e4 Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ea5f0d176a9d40df0ee6096203e1d1452f8db200 Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/42383d32d78acb13cc9a2245f037a73b39d4573b Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0b196d3db7138967d135b72ed9296a9ad7c06846 Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Prevent some buffer overruns in spell.c's parsing of affix files @ 2026-04-22 16:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-04-22 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/21a24d70950000741cc09866bc86e8be274f65df Modified Files -------------- src/backend/tsearch/spell.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-04-22 16:02 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us> 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us> 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us> 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us> 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us> 2026-04-22 16:02 pgsql: Prevent some buffer overruns in spell.c's parsing of affix files Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox