patch 9.0.2146: text-property without type errors when joining
Problem: text-property without type errors when joining
Solution: count all text-properties, with or without type
before joining lines
Error when joining lines with text properties without a proper type
When joining lines, we need to consider all text properties that are
attached to a line, even when those text properties are invalid and do
not have a type attached to them.
However, since patch v9.0.0993
(commit: 89469d157aea01513bde826b4519dd6b5fbceae4)
those text properties won't be counted when joining lines and therefore
this will cause the adjustment for text properties on joining to go
wrong (and may later cause SIGABRT with an invalid free pointer)
I am not sure, why the condition to not count text properties with a
valid type was added in patch v9.0.993, because no test fails if those
condition is removed. So let's just remove this condition and add a test
that verifies, that we are able to join lines, even when the text
properties attached to it do not have a valid type.
patch 9.0.2143: [security]: buffer-overflow in ex_substitute
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: #13596 Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.0.2142: [security]: stack-buffer-overflow in option callback functions
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.
patch 9.0.2141: [security]: buffer-overflow in suggest_trie_walk
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.
patch 9.0.2140: [security]: use-after-free in win-enter
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.
Peter Simonyi [Fri, 1 Dec 2023 17:07:42 +0000 (12:07 -0500)]
CI: check that all files are listed in Filelist (#13601)
Sometimes patches add files that should be included in tarballs for
distribution, but are not added to Filelist (used by Makefile to build
the tar archive). This can break the build, or it can be silently
ignored as runtime files are simply not included in the distribution.
Add a CI check to ensure all files tracked in the repository are
assigned to a variable in Filelist. A few files were not listed because
they do not need to be included in builds and tarballs, so add an IGNORE
variable for these exceptions.
Co-authored-by: Peter Simonyi <pts@petersimonyi.ca> Signed-off-by: Christian Brabandt <cb@256bit.org>
Peter Simonyi [Thu, 30 Nov 2023 16:46:55 +0000 (11:46 -0500)]
runtime(Filelist): include several missing files (#13600)
These files were discovered to be missing from Filelist, and thus
distribution tarballs:
- editorconfig plugin
- extra files for Rust support
- readme for Haiku OS builds
Co-authored-by: Peter Simonyi <pts@petersimonyi.ca> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Tue, 28 Nov 2023 19:46:29 +0000 (20:46 +0100)]
patch 9.0.2135: No test for mode() when executing Ex commands
Problem: No test for mode() when executing Ex commands
Solution: Add some test cases and simplify several other test cases.
Also add a few more test cases for ModeChanged.
closes: #13588
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
K.Takata [Tue, 28 Nov 2023 19:44:28 +0000 (04:44 +0900)]
runtime(lang): Revise Makefile (#13589)
* Revise runtime/lang/Makefile
* Use predefined variables (`$@`, `$<`) instead of the actual file names.
(Adding new rules should become easier.)
* Adjust spacing.
* Regenerate converted menu files
Problem: ml_get error when scrolling after delete
Solution: mark topline to be validated in main_loop
if it is larger than current buffers line
count
reset_lnums() is called after e.g. TextChanged autocommands and it may
accidentally cause curwin->w_topline to become invalid, e.g. if the
autocommand has deleted some lines.
So verify that curwin->w_topline points to a valid line and if not, mark
the window to have w_topline recalculated in main_loop() in
update_topline() after reset_lnums() returns.
* Add support for missing keywords to the nginx syntax plugin
This adds support for several keywords from
- the built-in HTTP/2 module,
- the built-in SSL module,
- the built-in uWSGI module,
- the experimental QUIC branch,
- the third-party SSL CT module,
- the third-party dynamic TLS records patch.
Ken Takata [Sat, 25 Nov 2023 14:51:00 +0000 (15:51 +0100)]
patch 9.0.2130: some errors with translation Makefiles
Problem: some errors with translation Makefiles
Solution: fix issues
Update src/po/ makefiles after 9.0.2127
* Change how to check `%LANGUAGE%`.
Check it only when needed.
* Add double quotes to where `GETTEXT_PATH` is used.
Before 9.0.2127, this worked: `nmake -f Make_mvc.mak GETTEXT_PATH="\"C:\Program Files\Git\usr\bin\""` (which was a bit tricky.)
9.0.2127 broke this and syntax error occurred.
This doesn't work either in 9.0.2127: `nmake -f Make_mvc.mak GETTEXT_PATH="C:\Program Files\Git\usr\bin"`
With this Commit, this works: `nmake -f Make_mvc.mak GETTEXT_PATH="C:\Program Files\Git\usr\bin"`
* Better error report for the `check` target.
Show the line number of the error. (Imported from vim-jp/lang-ja.)
closes: #13567
Signed-off-by: Ken Takata <kentkt@csc.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
mityu [Sat, 25 Nov 2023 14:41:20 +0000 (15:41 +0100)]
patch 9.0.2129: [security]: use-after-free in call_dfunc()
Problem: [security]: use-after-free in call_dfunc()
Solution: Refresh dfunc pointer
closes: #13571
This Commit fixes a SEGV caused by a use-after-free bug in call_dfunc().
When calling check_ufunc_arg_types() from the call_dfunc() it may cause
def functions to be re-compiled and if there are too many def functions,
the def_functions array will be re-allocated. Which means, that the
dfunc pointer in call_dfunc() now starts pointing to freed memory.
So we need to reset the dfunc pointer after calling
check_ufunc_arg_types().
Let's also add a test, to ensure we do not regress.
Julien Marrec [Sat, 25 Nov 2023 14:30:46 +0000 (15:30 +0100)]
patch 9.0.2128: runtime(swig): add syntax and filetype plugins
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript #1247 (which I found after writing this).
zeertzjq [Thu, 23 Nov 2023 19:47:16 +0000 (20:47 +0100)]
patch 9.0.2126: unused assignments when checking 'listchars'
Problem: Unused assignments when checking the value of 'listchars'.
Solution: Loop only once when just checking the value. Add a test to
check that this change doesn't cause double-free.
closes: #13559
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Thu, 23 Nov 2023 19:37:01 +0000 (20:37 +0100)]
patch 9.0.2125: File info disappears when 'cmdheight' has decreased
Problem: File info disappears immediately when 'cmdheight' has just
decreased due to switching tabpage and 'shortmess' doesn't
contain 'o' or 'O'.
Solution: Make sure msg_row isn't smaller than cmdline_row.
fixes: #13560
closes: #13561
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.0.2123: Problem with initializing the length of range() lists
Problem: Problem with initializing the length of range() lists
Solution: Set length explicitly when it shouldn't contain any items
range() may cause a wrong calculation of list length, which may later
then cause a segfault in list_find(). This is usually not a problem,
because range_list_materialize() calculates the length, when it
materializes the list.
In addition, in list_find() when the length of the range was wrongly
initialized, it may seem to be valid, so the check for list index
out-of-bounds will not be true, because it is called before the list is
actually materialized. And so we may eventually try to access a null
pointer, causing a segfault.
So this patch does 3 things:
- In f_range(), when we know that the list should be empty, explicitly
set the list->lv_len value to zero. This should happen, when
start is larger than end (in case the stride is positive) or
end is larger than start when the stride is negative.
This should fix the underlying issue properly. However,
- as a safety measure, let's check that the requested index is not
out of range one more time, after the list has been materialized
and return NULL in case it suddenly is.
- add a few more tests to verify the behaviour.
fixes: #13557
closes: #13563
Co-authored-by: Tim Pope <tpope@github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.0.2122: [security]: prevent overflow in indenting
Problem: [security]: prevent overflow in indenting
Solution: use long long and remove cast to (int)
The shiftwidth option values are defined as being long. However, when
calculating the actual amount of indent, we cast down to (int), which
may cause the shiftwidth value to become negative and later it may even
cause Vim to try to allocate a huge amount of memory.
We already use long and long long variable types to calculate the indent
(and detect possible overflows), so the cast to (int) seems superfluous
and can be safely removed. So let's just remove the (int) cast and
calculate the indent using longs.
Additionally, the 'shiftwidth' option value is also used when determining
the actual 'cino' options. There it can again cause another overflow, so
make sure it is safe in parse_cino() as well.
patch 9.0.2121: [security]: use-after-free in ex_substitute
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.
K.Takata [Wed, 22 Nov 2023 09:20:01 +0000 (18:20 +0900)]
runtime(netrw): Fix handling of very long filename on longlist style (#12150)
If there is a file with a very long filename (longer than
g:netrw_maxfilenamelen), and if g:netrw_liststyle is set to 1, no space
is inserted between the filename and the filesize and the file cannot be
opened because of this.
Then, it will be shown like this:
```
" ============================================================================
" Netrw Directory Listing (netrw v171)
" /cygdrive/c/work/netrw-test
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../ 0 Mon Mar 13 19:25:16 2023
./ 0 Mon Mar 13 19:44:58 2023 12345678901234567890123456789012 6 Mon Mar 13 19:29:43 2023 12345678901234567890123456789012346 Mon Mar 13 19:32:40 2023 1234567890123456789012345678901236 Mon Mar 13 19:29:49 2023
こんにちは 6 Mon Mar 13 19:30:41 2023
```
If the length of the filename is 32 bytes, there is a space between the
filename and the filesize. However, when it is longer than 32 bytes, no
space is shown.
Also, you may find that the filesize of the multibyte named file is not
aligned.
Now we have 32 + 2 + 15 = 49 characters for filename and filesize.
It tries to align the filesize as much as possible.
The last line that has multibyte filename is also aligned.
Also fixed the issue that the file list is not shown correctly when
g:netrw_sort_by is set to 'size' and g:netrw_sizestyle is set to 'h' or
'H'.
patch 9.0.2120: un-used assignment in do_source_buffer_init
Problem: un-used assignment in do_source_buffer_init
Solution: Remove it
Coverity warns about assigning NULL to line in scriptfile.c:1408,
because right after that assignment, in the next iteration of the loop,
line will be overwritten by the next value from vim_strsave().
And in case this was the last iteration, the line variable is no longer
used until the function returns. So we can safely remove that assignment.
Problem: remove dead-condition in ex_class()
Solution: remove the extra condition
The variable is_class must be true once we reach the
,----
| else if (has_static)
`----
in line 1750, because we break out earlier if is_class is false in line
1598 of vim9class.c. And once 'has_static = TRUE', we must be in a
class and there fore is_class is true.
patch 9.0.2118: [security]: avoid double-free in get_style_font_variants
Problem: [security]: avoid double-free
Solution: Only fee plain_font, when it is not the same as bold_font
When plain_font == bold_font and bold_font is not NULL, we may end up
trying to free bold_font again, which already has been freed a few lines
above.
So only free bold_font, when the condition gui.font_can_bold is true,
which means that bold_font is not pointing to plain_font (so it needs to
be freed separately).
runtime(netrw): expand $COMSPEC without applying 'wildignore' (#13542)
When expanding $COMSPEC and a user has set :set wildignore=*.exe
netrw won't be able to properly cmd.exe, because it does not ignore the
wildignore setting.
So let's explicitly use expand() without applying the 'wildignore' and
'suffixes' settings to the result
zdohnal [Tue, 21 Nov 2023 18:42:56 +0000 (19:42 +0100)]
runtime(Filelist): include new doc-Makefiles (#13551)
Tags for help files disappeared with the latest Vim update in Fedora,
which is caused by silent error (it didn't stop the build) about missing
file. I use 'make unixall' in Fedora to get the latest patchlevels and
the new files were missing from Filelist file which is used for
generating the tarball.
patch 9.0.2115: crash when callback function aborts because of recursiveness
Problem: crash when callback function aborts because of recursiveness
Solution: correctly initialize rettv
Initialize rettv in invoke_popup_callback()
Since v9.0.2030, call_callback may exit early when the callback recurses
too much. This meant that call_func, which would set rettv->v_type =
VAR_UNKNOWN, was not being called.
Without rettv->v_type being explicitly set, it still contained whatever
garbage was used to initialize the stack value in invoke_popup_callback.
This would lead to possible crashes when calling clear_tv(&rettv).
Rather than rely on action at a distance, explicitly initialize rettv's
type to VAR_UNKNOWN so clear_tv can tell nothing needs to be done.
closes: #13495
closes: #13545 Signed-off-by: James McCoy <jamessan@jamessan.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.0.2114: overflow detection not accurate when adding digits
Problem: overflow detection not accurate when adding digits
Solution: Use a helper function
Use a helper function to better detect overflows before adding integer
digits to a long or an integer variable respectively. Signal the
overflow to the caller function.
closes: #13539
Signed-off-by: Christian Brabandt <cb@256bit.org> Signed-off-by: Michael Henry <vim@drmikehenry.com> Signed-off-by: Ernie Rael <errael@raelity.com>
patch 9.0.2113: Coverity warns for another overflow in shift_line()
Problem: Coverity warns for another overflow in shift_line()
Solution: Test for INT_MAX after the if condition, cast integer values
to (long long) before multiplying.
Signed-off-by: Christian Brabandt <cb@256bit.org> Signed-off-by: Michael Henry <vim@drmikehenry.com> Signed-off-by: Ernie Rael <errael@raelity.com>
patch 9.0.2112: [security]: overflow in shift_line
Problem: [security]: overflow in shift_line
Solution: allow a max indent of INT_MAX
[security]: overflow in shift_line
When shifting lines in operator pending mode and using a very large
value, we may overflow the size of integer. Fix this by using a long
variable, testing if the result would be larger than INT_MAX and if so,
indent by INT_MAX value.
Special case: We cannot use long here, since on 32bit architectures (or
on Windows?), it typically cannot take larger values than a plain int,
so we have to use long long count, decide whether the resulting
multiplication of the shiftwidth value * amount is larger than INT_MAX
and if so, we will store INT_MAX as possible larges value in the long
long count variable.
Then we can safely cast it back to int when calling the functions to set
the indent (set_indent() or change_indent()). So this should be safe.
Add a test that when using a huge value in operator pending mode for
shifting, we will shift by INT_MAX
patch 9.0.2111: [security]: overflow in get_number
Problem: [security]: overflow in get_number
Solution: Return 0 when the count gets too large
[security]: overflow in get_number
When using the z= command, we may overflow the count with values larger
than MAX_INT. So verify that we do not overflow and in case when an
overflow is detected, simply return 0
patch 9.0.2108: [security]: overflow with count for :s command
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
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.
rhysd [Tue, 14 Nov 2023 15:46:07 +0000 (16:46 +0100)]
patch 9.0.2104: wast filetype should be replaced by wat filetype
Problem: wast filetype should be replaced by wat filetype
Solution: start using the official wat filetype name
runtime: rename `wast` filetype to `wat` (Wasm text format)
The problem is the name of the current filetype wast. When the plugin
was initially created, the file extension for Wasm text format was not
fixed and .wast was more popular.
However, recently .wat became the official file extension for
WebAssembly text (WAT) format and .wast is now a file extension for the
unofficial WAST format, which is a superset of .wat for the convenience
to describe the Wasm specification conformance tests.
However for now, let's keep using the `wat` filetype even for the .wast
extension, so that we at least do not lose the filetype settings and
syntax highlighting. This can be adjusted later, if it turns out to have
a separate need for.
closes: #13533
Signed-off-by: rhysd <lin90162@yahoo.co.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.0.2103: recursive callback may cause issues on some archs
Problem: recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20
Recursive callback limit causes problems on some architectures
Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).
So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).
Nir Lichtman [Sat, 11 Nov 2023 10:27:41 +0000 (11:27 +0100)]
patch 9.0.2099: win32: terminal codes clear the terminal
Problem: Terminal control codes¹ are sent even when silent
mode is on, causing the terminal to clear up
Solution: Block any terminal codes when silent mode is on
patch 9.0.2095: statusline may look different than expected
Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
Do not rely on the fact, that the last line matches warning, error,
inappropriate or unrecognized to determine if an error occurred. It
could also be a file, contains such a keyword.
So make the error detection slightly more strict and only assume an
error occured, if in addition to those 4 keywords, also a space matches
(this assumes the error message contains a space), which luckily on Unix
not many files match by default.
The whole if condition seems however slightly dubious. In case an error
happened, this would probably already be caught in the previous if
statement, since this checks for the return code of the tar program.
There may however be tar implementations, that do not set the exit code
for some kind of error (but print an error message)? But let's keep this
check for now, not many people have noticed this behaviour until now, so
it seems to work reasonably well anyhow.
related: #6425
fixes: #13489 Signed-off-by: Christian Brabandt <cb@256bit.org>
projects / thirdparty / vim.git / log
