Problem: possible crash when calculating topline in diff.c
(youngmith)
Solution: Check for pointer being Null before accessing it
fixes: vim/vim#18437d32b3bb7eb
The POC is likely not applicable to Nvim due to #32160.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Vim tests are slow and flaky at the same time due to reliance
on timeouts which are unreliable.
Solution: improve Vim test performance and reduce flakiness
(Yee Cheng Chin)
A lot of Vim tests currently rely on waiting a specific amount of time
before asserting a condition. This is bad because 1) it is slow, as the
timeout is hardcoded, 2) it's unreliable as a resource-starved runner
may overshoot the timeout. Also, there are a lot of builtin sleep
commands in commonly used utilities like VerifyScreenDump and WaitFor()
which leads to a lot of unnecessary idle time.
Fix these issues by doing the following:
1. Make utilities like VerifyScreenDump and WaitFor use the lowest wait
time possible (1 ms). This essentially turns it into a spin wait. On
fast machines, these will finish very quickly. For existing tests
that had an implicit reliance on the old timeouts (e.g.
VerifyScreenDump had a 50ms wait before), fix the tests to wait that
specific amount explicitly.
2. Fix tests that sleep or wait for long amounts of time to instead
explicitly use a callback mechanism to be notified when a child
terminal job has finished. This allows the test to only take as much
time as possible instead of having to hard code an unreliable
timeout.
With these fixes, tests should 1) completely quickly on fast machines,
and 2) on slow machines they will still run to completion albeit slowly.
Note that previoulsy both were not true. The hardcoded timeouts meant
that on fast machines the tests were mostly idling wasting time, whereas
on slow machines, the timeouts often were not generous enough to allow
them to run to completion.
closes: vim/vim#16615e70587dbdb
Part of shared.vim and test_crash.vim changes only.
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: tests: "Untitled" file not removed when running Test_crash1_3 alone
with TEST_FILTER (after v9.1.0695)
Solution: Use a TearDown function instead of another test.
(zeertzjq)
closes: vim/vim#15578closes: vim/vim#15577d56c451e1c
Problem: tests: test_crash leaves Untitled file around
Solution: cleanup at the end of the test_crash.vim test file
cd83173def
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: buffer-overflow in do_search() with 'rightleft'
(SuyueGuo)
Solution: after reversing the text (which allocates a new buffer),
re-calculate the text length
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-v2x2-cjcg-f9jmcacb6693c1
Add missing change from patch 8.1.1270.
Omit `call delete('Untitled')`: moved again in patch 9.1.0695.
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: 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>
