| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: A crafted swap file can cause an out-of-bounds write during
recovery when the same block is referenced twice with
different pe_page_count values (cipher-creator)
Solution: Check hp->bh_page_count against page_count after mf_get() and
clamp page_count to the actual block size.
closes: vim/vim#20645
https://github.com/vim/vim/commit/43939cf9ebf5302bb51c85d00ac83de7e01452d5
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
| |
Problem: #39625 retained `matchparen.vim` as a shim that sources the new
`matchparen.lua` entrypoint, which is redundant since Lua runtime/plugin
files are sourced automatically and incurs startuptime cost solely for
the sake of not touching the tests.
Solution: Remove the shim and `source` the Lua plugin in directly in
tests.
|
| |
|
|
|
|
|
|
|
|
| |
Problem: runtime(zip): may write using absolute paths
(syndicate)
Solution: Detect this case and abort on Unix, warn in the documentation
about possible issues
https://github.com/vim/vim/commit/46f530e517bd1b59acc2eb0d2aa76d02e54ca9fe
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: [security]: path traversal issue in zip.vim
(Michał Majchrowicz)
Solution: Detect more such attacks and warn the user.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-jc86-w7vm-8p24
https://github.com/vim/vim/commit/7088926316d8d4a7572a242d0765e99adfc8b083
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#38104)
Problem: memline: a crafted swap files with bogus pe_page_count/pe_bnum
values could cause a multi-GB allocation via mf_get(), and
invalid pe_old_lnum/pe_line_count values could cause a SEGV
when passed to readfile() (ehdgks0627, un3xploitable)
Solution: Add bounds checks on pe_page_count and pe_bnum against
mf_blocknr_max before descending into the block tree, and
validate pe_old_lnum >= 1 and pe_line_count > 0 before calling
readfile().
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-r2gw-2x48-jj5p
https://github.com/vim/vim/commit/65c1a143c331c886dc28888dd632708f953b4eb3
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: No test that undofile format does not regress
Solution: include a sample undofile to make sure we are always able to
read it
This is so, that we don't unintentionally change the undofile format and
make sure we can load an undo file that has been created by an older
Vim.
closes: vim/vim#16127
https://github.com/vim/vim/commit/14382c8bc96cc8f3985a01ab58c2f4d7b4d9ec85
Convert the undo file in samples/ using method from #13973.
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
chars (#37133)
Problem: Buffer overflow in buf_write() when converting incomplete
multi-byte characters (Kevin Goodsell)
Solution: Make the buffer slightly larger
closes: vim/vim#19007
https://github.com/vim/vim/commit/f99de42a9fbc2caaac2741a275b6c25421582cf4
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: [security]: path traversal issue in tar.vim
(@ax)
Solution: warn the user for such things, drop leading /, don't
forcefully overwrite files when writing temporary files,
refactor autoload/tar.vim
tar.vim: drop leading / in path names
A tar archive containing files with leading `/` may cause confusions as
to where the content is extracted. Let's make sure we drop the leading
`/` and use a relative path instead.
Also while at it, had to refactor it quite a bit and increase the
minimum supported Vim version to v9. Also add a test for some basic tar
functionality
closes: vim/vim#17733
https://github.com/vim/vim/commit/87757c6b0a4b2c1f71c72ea8e1438b8fb116b239
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: [security]: path traversal issue in zip.vim (@ax)
Solution: drop leading ../ on write of zipfiles, don't forcefully
overwrite existing files
A zip plugin which contains filenames with leading '../' may cause
confusion as to where the content will be extracted. Let's drop such
things and make sure we use a relative filename instead and don't
forcefully overwrite temporary files. Also, warn the user of such
things.
related: vim/vim#17733
https://github.com/vim/vim/commit/586294a04179d855c3d1d4ee5ea83931963680b8
vim-patch:e1044fb: runtime(zip): raise minimum Vim version to v9.0
vim-patch:e2d9b0d: runtime(zip): zip plugin does not work with Vim 9.0
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: [security]: potential data loss with zip.vim and special
crafted zip files (RyotaK)
Solution: use glob '[-]' to protect filenames starting with '-'
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-693p-m996-3rmf
https://github.com/vim/vim/commit/f209dcd3defb95bae21b2740910e6aa7bb940531
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: zip-plugin has problems with special characters
(user202729)
Solution: escape '*?[\' on Unix and handle those chars
a bit differently on MS-Windows, add a test, check
before overwriting files
runtime(zip): small fixes for zip plugin
This does the following:
- verify the unzip plugin is executable when loading the autoload plugin
- handle extracting file names with '[*?\' in its name correctly by
escaping those characters for the unzip command (and handle those
characters a bit differently on MS-Windows, since the quoting is different)
- verify, that the extract plugin is not overwriting a file (could cause
a hang, because unzip asking for confirmation)
- add a test zip file which contains those special file names
fixes: vim/vim#15505
closes: vim/vim#15519
https://github.com/vim/vim/commit/7790ea0c680a9f951a86066e5940ec16b2333c9a
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
| |
Problem: the zip plugin is not tested.
Solution: include tests (Damien)
closes: vim/vim#15411
https://github.com/vim/vim/commit/d7af21e746f3992c650caf6b76465880b96302b4
Co-authored-by: Damien <141588647+xrandomname@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
fixes: vim/vim#13568
fixes: vim/vim#13578
https://github.com/vim/vim/commit/c4ffeddfe5bd1824650e9b911ed9245bf56c69e3
The error doesn't happen in Nvim because Nvim triggers TextChanged after
calling update_topline().
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
|
|
|
The new oldtest directory is in test/old/testdir. The reason for this is
that many tests have hardcoded the parent directory name to be
'testdir'.
|
