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>
This reverts commit fe30d8ccef.
The original commit intends to prevent heap-use-after-free with EXITFREE
caused by changedtick_di, which is no longer a problem.
Freeing buffers after freeing variables will cause heap-use-after-free
with EXITFREE when a partial is used as prompt callback.
Problem: html.angular ft is problematic
Solution: partly revert v9.0.2137
The html.angular filetype causes issues and does not trigger FileType
autocommands for the html or angular filetypes.
So let's roll back that particular change and detect this only as html
file
related: https://github.com/vim/vim/pull/13594#issuecomment-1834465890closes: vim/vim#136044f3480c943
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
`LanguageTree:for_each_tree` calls itself for child nodes, so when we
calls `for_each_tree` inside `for_each_tree`, this quickly leads to
exponential tree calls.
Solution:
Use `pairs(child:trees())` directly in this case, as we don't need the
extra callback for each children, this is already handled from the outer
`for_each_tree` call
Some escape sequences (in particular, OSC 52 paste responses) can be
very large, even unbounded in length. These can easily overflow
termkey's internal buffer. In order to process these long sequences,
dynamically grow termkey's internal buffer.
When first opened, the tree-sitter inspector traverses all of the nodes
in the buffer to calculate an array of nodes. This traversal is done
only once, and _all_ nodes (both named and anonymous) are included.
Toggling anonymous nodes in the inspector only changes how the tree is
drawn in the buffer, but does not affect the underlying data structure
at all.
When the buffer is traversed and the list of nodes is calculated, we
don't know whether or not anonymous nodes will be displayed in the
inspector or not. Thus, we cannot determine during traversal where to
put closing parentheses. Instead, this must be done when drawing.
When we draw, the tree structure has been flatted into a single array,
so we lose parent-child relationships that would otherwise make
determining the number of closing parentheses straightforward. However,
we can instead rely on the fact that a delta between the depth of a node
and the depth of the successive node _must_ mean that more closing
parentheses are required:
(foo
(bar)
(baz) ↑
│
└ (bar) and (baz) have different depths, so (bar) must have an
extra closing parenthesis
This does not depend on whether or not anonymous nodes are displayed and
so works in both cases.
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
runtime(html): Update syntax file (vim/vim#13591)
Add missing search element and update ARIA attribute list.
Add a very basic test file to check all elements are matched.
a9058440b7
Co-authored-by: dkearns <dougkearns@gmail.com>
The OptionSet autocommand does not fire until Vim has finished starting,
so setting 'background' before the VimEnter event would not fire the
OptionSet event. The prior implementation also waited until VimEnter to
set 'background', so this was a regression introduced when moving
background detection into Lua.
