diff options
author | zeertzjq <zeertzjq@outlook.com> | 2024-12-10 13:24:54 +0800 |
---|---|---|
committer | zeertzjq <zeertzjq@outlook.com> | 2024-12-10 14:29:24 +0800 |
commit | 2336389d236f3d80575a5139e92c551c005b0eff (patch) | |
tree | 0979fe1164b1e13625384a11b03590ca365d6849 /runtime/lua/vim/_buf.lua | |
parent | 4889935a7a0e188d6fb247cbc3b3bb0c5b0ed731 (diff) | |
download | rneovim-2336389d236f3d80575a5139e92c551c005b0eff.tar.gz rneovim-2336389d236f3d80575a5139e92c551c005b0eff.tar.bz2 rneovim-2336389d236f3d80575a5139e92c551c005b0eff.zip |
vim-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
closes: vim/vim#13535
https://github.com/vim/vim/commit/6bf131888a3d1de62bbfa8a7ea03c0ddccfd496e
Skip the test for now, as it takes too long and requires other fixes.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Diffstat (limited to 'runtime/lua/vim/_buf.lua')
0 files changed, 0 insertions, 0 deletions