Problem: [security]: use-after-free in ex_substitute
Solution: always allocate memory
closes: #13552
A recursive :substitute command could cause a heap-use-after free in Vim
(CVE-2023-48706).
The whole reproducible test is a bit tricky, I can only reproduce this
reliably when no previous substitution command has been used yet
(which is the reason, the test needs to run as first one in the
test_substitute.vim file) and as a combination of the `:~` command
together with a :s command that contains the special substitution atom `~\=`
which will make use of a sub-replace special atom and calls a vim script
function.
There was a comment in the existing :s code, that already makes the
`sub` variable allocate memory so that a recursive :s call won't be able
to cause any issues here, so this was known as a potential problem
already. But for the current test-case that one does not work, because
the substitution does not start with `\=` but with `~\=` (and since
there does not yet exist a previous substitution atom, Vim will simply
increment the `sub` pointer (which then was not allocated dynamically)
and later one happily use a sub-replace special expression (which could
then free the `sub` var).
The following commit fixes this, by making the sub var always using
allocated memory, which also means we need to free the pointer whenever
we leave the function. Since sub is now always an allocated variable,
we also do no longer need the sub_copy variable anymore, since this one
was used to indicated when sub pointed to allocated memory (and had
therefore to be freed on exit) and when not.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large
If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.
Adds a test with INT_MAX as count and verify it correctly fails.
It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: RedrawingDisabled not used consistently.
Solution: Avoid RedrawingDisabled going negative. Set RedrawingDisabled in
win_split_ins(). (closes#11961)
Problem: Search error message doesn't show used pattern.
Solution: Pass the actually used pattern to where the error message is
given. (Rob Pilling, closes#11742)
Problem: Shell command with just space gives strange error.
Solution: Skip white space at start of the argument. (Christian Brabandt,
Shane-XB-Qian, closes#11515, closes#11495)
Problem: ":!" doesn't do anything but does update the previous command.
Solution: Do not have ":!" change the previous command. (Martin Tournoij,
closes#11372)
Problem: Too many #ifdefs.
Solution: Graduate the +cmdwin feature. Now the tiny and small builds are
equal, drop the small build. (Martin Tournoij, closes#11268)
Problem: When using powershell input redirection does not work.
Solution: Use a different shell command for powershell. (Yegappan
Lakshmanan, closes#11257)
Problem: The command line takes up space even when not used.
Solution: Allow for 'cmdheight' to be set to zero. (Shougo Matsushita,
closes#10675, closes#940)
Problem: When 'insermode' is set :edit from <Cmd> mapping misbehaves.
Solution: Don't set "need_start_insertmode" when already in Insert mode.
(closes#10116)
