Problem: Crash when reading truncated spellfile (MarkLee131)
Solution: Set sl_sofo to TRUE in set_sofo() once sl_sal has been
converted to the soundfold layout.
Supported by AI.
closes: vim/vim#20660488a3eed12
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: A crafted spell file with non-collapsing SAL rules
can make soundfold() write one byte past the end of the
MAXWLEN result buffer. This is the same class of
out-of-bounds write as GHSA-q8mh-6qm3-25g4 (fixed in 9.2.0698
for the SOFO branch), found while auditing the surrounding
code.
Solution: Bound the single-byte SAL result writes and the terminating
NUL to MAXWLEN - 1, matching the SOFO branch.
The single-byte branch of spell_soundfold_sal() guarded its writes with
"reslen < MAXWLEN", allowing reslen to reach MAXWLEN (254). The trailing
"res[reslen] = NUL" then wrote at index 254 of the 254-byte stack buffer
res[MAXWLEN], an off-by-one out-of-bounds write. Input is case-folded to
about 253 characters, so a 253-character argument together with a SAL map
that does not collapse (collapse_result false) reaches the boundary.
Related to previous issue
[GHSA-q8mh-6qm3-25g4](https://github.com/vim/vim/security/advisories/GHSA-q8mh-6qm3-25g4)
(9.2.0698)
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-m3hf-xcm3-xhm2d22ff1c955
This is N/A as Nvim doesn't have spell_soundfold_sal() which is only
used in the !has_mbyte code path.
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem: [security]: Out-of-bounds write with soundfold()
(cipher-creator)
Solution: Add an abort condition to the for loop to validate the buffer
size.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q8mh-6qm3-25g4
Supported by AI
497f931f85
This is N/A as it only changes the !has_mbyte code path.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: a crafted spell file can drive tree_count_words()
past the end of its MAXWLEN-sized depth arrays; the descent
loop has no depth bound.
Solution: only descend while depth < MAXWLEN - 1, as the sibling trie
walkers already do; apply the same guard to sug_filltree().
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-wgh4-64f7-q3jq
Supported by AI.
a80874d9b8
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: spell: a word in a .dic file with many postponed prefix or
compound flags overflows the fixed-size store_afflist[MAXWLEN]
buffer in get_pfxlist() and get_compflags().
Solution: Add bounds checks (Yasuhiro Matsumoto).
closes: vim/vim#202869a920e8254
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: read_compound() in spellfile.c computes the size of the regex
pattern buffer using signed-int arithmetic on the attacker
controlled SN_COMPOUND sectionlen. With sectionlen=0x40000008
and UTF-8 encoding active the multiplication wraps to 27 while
the per-byte loop writes up to ~1B bytes, overflowing the heap.
Reachable when loading a crafted .spl file (e.g. via 'set spell'
after a modeline sets 'spelllang'). The cp/ap/crp allocations
have the same int + 1 overflow class (Daniel Cervera)
Solution: Use type size_t as buffer size and reject values larger than
COMPOUND_MAX_LEN (100000). Apply the same size_t treatment to
the cp/ap/crp allocations.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q4jv-r9gj-6cwv9299332917
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Problem: spell_read_aff() uses sprintf() into a fixed-size stack buffer
without bounds checking. store_aff_word() uses STRCAT() to
append attacker-controlled strings into newword[MAXWLEN] without
checking remaining space. Both are reachable via :mkspell with
crafted .aff/.dic files (xinyi234)
Solution: Replace sprintf() with vim_snprintf() in spell_read_aff().
Replace STRCAT() with STRNCAT() with explicit remaining-space
calculation in store_aff_word().
closes: vim/vim#1994407faa961a0
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
First rtp directory is unpredictable and not in line with XDG
base spec.
Solution:
Use stdpath('data')/spell as directory if 'spellfile' is not set.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: E1510 may happen when formatting a message
(after 9.1.0181).
Solution: Only give E1510 when using typval. (zeertzjq)
closes: vim/vim#153910dff31576a
Problem: Too many delete() calls in tests.
Solution: Use deferred delete where possible.
56564964e6
This includes all changes expect changes in test_startup.vim.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Spellfile code not completely tested.
Solution: Add a few more test cases. (Yegappan Lakshmanan, closesvim/vim#6929)
96fdf4348a
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Spellfile code not completely tested.
Solution: Add a few more test cases. (Yegappan Lakshmanan, closesvim/vim#6918)
64e2db6dc6
Fix incorrect spellfile message.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Crash when using ":mkspell" with an empty .dic file.
Solution: Check for an empty word tree.
6669de1b23
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Not enough characters accepted for 'spellfile'.
Solution: Add vim_is_fname_char() and use it for 'spellfile'.
bc49c5f48f
Cherry-pick related doc update from Vim runtime.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
