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-xc2f

https://github.com/vim/vim/commit/b29f4abcd4b3382fa746edd1d0562b7b48c9de60

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-hcr4

https://github.com/vim/vim/commit/8a0bbe7b8aad6f8da28dee218c01bc8a0185a2d5

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#13652

https://github.com/vim/vim/commit/0f28791b215bd4c22ed580839409c2f7d39d8140

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#13621

https://github.com/vim/vim/commit/5dd41d4b6370b7b7d09d691f9252b3899c66102a

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#13596

https://github.com/vim/vim/commit/abfa13ebe92d81aaf66669c428d767847b577453

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!

https://github.com/vim/vim/commit/b39b240c386a5a29241415541f1c99e2e6b8ce47

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!

https://github.com/vim/vim/commit/0fb375aae608d7306b4baf9c1f906961f32e2abf

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!

https://github.com/vim/vim/commit/eec0c2b3a4cfab93dd8d4adaa60638d47a2bbc8a

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

https://github.com/vim/vim/commit/25aabc2b8ee1e19ced6f4da9d866cf9378fc4c5a

Co-authored-by: Christian Brabandt <cb@256bit.org>

Problem:  [security] use-after-free from buf_contents_changed()
Solution: block autocommands

https://github.com/vim/vim/commit/41e6f7d6ba67b61d911f9b1d76325cd79224753d

Co-authored-by: Christian Brabandt <cb@256bit.org>