Problem: [security] double-free in dialog_changed()
(SuyueGuo)
Solution: Only clear pointer b_sfname pointer, if it is different
than the b_ffname pointer. Don't try to free b_fname,
set it to NULL instead.
fixes: vim/vim#15403
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-46pw-v7qw-xc2fb29f4abcd4
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security] use-after-free in tagstack_clear_entry
(Suyue Guo )
Solution: Instead of manually calling vim_free() on each of the tagstack
entries, let's use tagstack_clear_entry(), which will
also free the stack, but using the VIM_CLEAR macro,
which prevents a use-after-free by setting those pointers
to NULL
This addresses CVE-2024-41957
Github advisory:
https://github.com/vim/vim/security/advisories/GHSA-f9cr-gv85-hcr48a0bbe7b8a
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in check_argument_type
Solution: Reset function type pointer when freeing the function type
list
function pointer fp->uf_func_type may point to the same memory, that was
allocated for fp->uf_type_list. However, when cleaning up a function
definition (e.g. because it was invalid), fp->uf_type_list will be
freed, but fp->uf_func_type may still point to the same (now) invalid
memory address.
So when freeing the fp->uf_type_list, check if fp->func_type points to
any of those types and if it does, reset the fp->uf_func_type pointer to
the t_func_any (default) type pointer
closes: vim/vim#136520f28791b21
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in exec_instructions()
Solution: get tv pointer again
[security]: use-after-free in exec_instructions()
exec_instructions may access freed memory, if the GA_GROWS_FAILS()
re-allocates memory. When this happens, the typval tv may still point to
now already freed memory. So let's get that pointer again and compare it
with tv. If those two pointers differ, tv is now invalid and we have to
refresh the tv pointer.
closes: vim/vim#136215dd41d4b63
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: buffer-overflow in ex_substitute
Solution: clear memory after allocating
When allocating the new_start pointer in ex_substitute() the memory
pointer points to some garbage that the following for loop in
ex_cmds.c:4743 confuses and causes it to accessing the new_start pointer
beyond it's size, leading to a buffer-overlow.
So fix this by using alloc_clear() instead of alloc(), which will
clear the memory by NUL and therefore cause the loop to terminate
correctly.
Reported by @henices, thanks!
closes: vim/vim#13596abfa13ebe9
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: stack-buffer-overflow in option callback functions
Solution: pass size of errbuf down the call stack, use snprintf()
instead of sprintf()
We pass the error buffer down to the option callback functions, but in
some parts of the code, we simply use sprintf(buf) to write into the error
buffer, which can overflow.
So let's pass down the length of the error buffer and use sprintf(buf, size)
instead.
Reported by @henices, thanks!
b39b240c38
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: buffer-overflow in suggest_trie_walk
Solution: Check n before using it as index into byts array
Basically, n as an index into the byts array, can point to beyond the byts
array. So let's double check, that n is within the expected range after
incrementing it from sp->ts_curi and bail out if it would be invalid.
Reported by @henices, thanks!
0fb375aae6
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in win-enter
Solution: validate window pointer before calling win_enter()
win_goto() may stop visual mode, if it is active. However, this may in
turn trigger the ModeChanged autocommand, which could potentially free
the wp pointer which was valid before now became stale and points to now
freed memory.
So before calling win_enter(), let's verify one more time, that the
wp pointer still points to a valid window structure.
Reported by @henices, thanks!
eec0c2b3a4
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
25aabc2b8e
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: buffer-overflow in trunc_string()
Solution: Add NULL at end of buffer
Currently trunc_string() assumes that when the string is too long,
buf[e-1] will always be writeable. But that assumption may not always be
true. The condition currently looks like this
else if (e + 3 < buflen)
[...]
else
{
// can't fit in the "...", just truncate it
buf[e - 1] = NUL;
}
but this means, we may run into the last else clause with e still being
larger than buflen. So a buffer overflow occurs.
So instead of using `buf[e - 1]`, let's just always
truncate at `buf[buflen - 1]` which should always be writable.
3bd7fa12e1
vim-patch:9.0.2004: Missing test file
Problem: Missing test file
Solution: git-add the file to the repo
closes: vim/vim#13305d4afbdd071
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Trailing white space in tests
Solution: Delete it
This causes test_codestyle to fail, so we need to remove it again.
Hopefully that makes the CI green again.
Note: I will start using annotated tags from now on.
da200c2f78
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: tests running sh have problems
Solution: Check that dash is installed
closes: vim/vim#130401690ec64ff
Co-authored-by: Philip H <47042125+pheiduck@users.noreply.github.com>
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active
f6d28fe2c9
Cherry-pick test_crash.vim change from patch 9.0.1876.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: crash with bt_quickfix1_poc when cleaning up
and EXITFREE is defined
Solution: Test if buffer is valid in a window, else close
window directly, don't try to access buffer properties
While at it, increase the crash timeout slightly, so that CI has a
chance to finish processing the test_crash() test.
623ba31821
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in bt_normal()
Solution: check that buffer is still valid
6e60cf444a
Test change only.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap use after free in ins_compl_get_exp()
Solution: validate buffer before accessing it
ee9166eb3b
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in is_qf_win()
Solution: Check buffer is valid before accessing it
fc68299d43
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: test_crash1() fails on CI
Solution: don't run Screendump test, verify that it doesn't crash
by running it through a shell command line, testing
the exit value and concatenating success cmd using '&&'
db510ca805
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: buffer-overflow in vim_regsub_both()
Solution: Check remaining space
ced2c7394a
The change to do_sub() looks confusing. Maybe it's an overflow check?
Then the crash may not be applicable to Nvim because of different casts.
The test also looks confusing. It seems to source itself recursively.
Also don't call strlen() twice on evaluation result.
N/A patches for version.c:
vim-patch:9.0.1849: CI error on different signedness in ex_cmds.c
vim-patch:9.0.1853: CI error on different signedness in regexp.c
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: use-after-free in do_ecmd
Solution: Verify oldwin pointer after reset_VIsual()
e1dc9a6275
N/A patches for version.c:
vim-patch:9.0.1841: style: trailing whitespace in ex_cmds.c
Co-authored-by: Christian Brabandt <cb@256bit.org>
