Commit Graph

8 Commits

Author SHA1 Message Date
zeertzjq
790bd4d585 vim-patch:9.0.2106: [security]: Use-after-free in win_close()
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>
2023-11-17 09:59:22 +08:00
zeertzjq
d49be1cd28 vim-patch:9.0.2010: [security] use-after-free from buf_contents_changed()
Problem:  [security] use-after-free from buf_contents_changed()
Solution: block autocommands

41e6f7d6ba

Co-authored-by: Christian Brabandt <cb@256bit.org>
2023-11-17 09:59:22 +08:00
zeertzjq
b6200fbdf2 vim-patch:9.0.1992: [security] segfault in exmode
Problem:  segfault in exmode when redrawing
Solution: skip gui_scroll when exmode_active

20d161ace3

Co-authored-by: Christian Brabandt <cb@256bit.org>
2023-11-17 09:59:22 +08:00
zeertzjq
3ab0e296c6 vim-patch:9.0.1969: [security] buffer-overflow in trunc_string()
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#13305

d4afbdd071

Co-authored-by: Christian Brabandt <cb@256bit.org>
2023-11-17 09:59:16 +08:00
zeertzjq
bbb363f4bc vim-patch:partial:9.0.1859: heap-use-after-free in bt_normal()
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>
2023-11-17 09:54:03 +08:00
zeertzjq
8dc72789cf vim-patch:9.0.1858: [security] heap use after free in ins_compl_get_exp()
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>
2023-11-17 09:54:03 +08:00
zeertzjq
a589156b4d vim-patch:9.0.1857: [security] heap-use-after-free in is_qf_win()
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>
2023-11-17 09:54:03 +08:00
zeertzjq
bebdf1dab3 vim-patch:9.0.1848: [security] buffer-overflow in vim_regsub_both() (#25001)
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>
2023-09-03 13:47:55 +08:00