New patchlevel 9.0.2116 · Pull Request !32 · src-anolis-os/vim

- https://github.com/vim/vim/security/advisories/GHSA-8g46-v9ff-c765 (CVE-2023-48231)
When closing a window, vim may try to access already freed window structure. So before trying to access any window related variable verify that the window to be closed is still valid and if not, return.
Impact is low, since it is not very easy to make use of this and execute some payload (in particular not, without the user noticing).

- https://github.com/vim/vim/security/advisories/GHSA-f6cx-x634-hqpw (CVE-2023-48232)
A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag.
This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag.
Impact is rather low, since we do not expect many users to have those non-default setting set.

- https://github.com/vim/vim/security/advisories/GHSA-3xx4-hcq6-r2vj (CVE-2023-48233)
If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large.
Impact is low, user interaction is required and a crash may not even happen.

- https://github.com/vim/vim/security/advisories/GHSA-59gw-c949-6phq (CVE-2023-48234)
When getting the count for a normal mode z command, it may overflow for large counts given. So let's verify that the result can be safely stored, else abort the z command.
Impact is low, user interaction is required and a crash may not even happen.

- https://github.com/vim/vim/security/advisories/GHSA-6g74-hr6q-pr8g (CVE-2023-48235)
When parsing relative ex addresses one may unintentionally cause an overflow. Ironacially this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow.
Impact is low, user interaction is required and a crash may not even happen.
So verify that the line numer is actually positive before doing the actual overflow check.

- https://github.com/vim/vim/security/advisories/GHSA-pr4c-932v-8hx5 (CVE-2023-48236)
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
Impact is low, user interaction is required and a crash may not even happen.

- https://github.com/vim/vim/security/advisories/GHSA-f2m2-v387-gv87 (CVE-2023-48237)
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 long variable, testing if the result would be larger than INT_MAX and if so, indent by INT_MAX value.
Impact is low, user interaction is required and a crash may not even happen.

- https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q (CVE-2023-48706)
When executing a :s command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive :s call causes free-ing of memory which may later then be accessed by the initial :s comamnd.
Impact is low since the user must intentionally execute the payload and the whole process is a bit tricky to do (since it seems to work only reliably for the very first :s command). It may also cause a crash of Vim.

类型	指派人员	状态
审查	happy_orange 已审查通过	已完成 (1/0人)
测试	小龙已测试通过	已完成 (1/1人)

src-anolis-os/vim .gitee-modal { width: 500px !important; }

搜索帮助

src-anolis-os/vim