vim-9.1.???? (Update before release)

[Bruce Dubbs]

Update vim to latest patch version before release.

[Bruce Dubbs]

Updated to vim-8.1.1846 at revision 11656.

Leaving ticket open.

[Bruce Dubbs]

vim-8.2.0000 is available.

Promoting to milestone 9.1 so we put it in now, but should probably move the ticket back to future after that update.

[Bruce Dubbs]

Release notes for 8.2 are at

​https://www.vim.org/vim-8.2-released.php

[Pierre Labastie]

Updated to 8.2.0024 at r11711

[Bruce Dubbs]

Updated to version 8.2.0129 at revision 11731.

[Bruce Dubbs]

Updated to version 8.2.0190 at revision 11738.

[Douglas R. Reno]

Updating vim again at the next LFS update would be a good idea.

On 10/4/21 08:48, Alan Coopersmith wrote:
> On 9/30/2021 7:39 PM, Alan Coopersmith wrote:
>> I haven't seen these make it to the list yet, but three CVE's were
>> recently assigned for bugs in vim.  [I personally don't see how
>> there's a security boundary crossed in normal vim usage here, but
>> could see issues if someone had configured vim to run with raised
>> privileges for editing system/application configuration files or
>> similar.]
>
> I do note all three of these were submitted via huntr.dev, which offers
> bounties for both reporting & fixing security bugs.  As a maintainer of
> an upstream open source project which is struggling with finding people
> to fix reported security bugs [1], I do appreciate the additional
> incentive to provide fixes here.  But as a maintainer of a distro, I see
> a mismatch with the incentives here, as you get bounties for accepting
> everything as a security bug and not pushing back, and flooding the
> distros with CVE's - even if your distro policy isn't to handle every
> CVE that applies, security auditors will often make your users query
> about every CVE that they think applies, costing your time to respond.
>
> [1] https://indico.freedesktop.org/event/1/contributions/28/
> https://www.youtube.com/watch?v=IU3NeVvDSp0

This has continued with many more CVE's issued for vim:

CVE-2022-0213     vim is vulnerable to Heap-based Buffer Overflow
CVE-2022-0158     vim is vulnerable to Heap-based Buffer Overflow
CVE-2022-0156     vim is vulnerable to Use After Free
CVE-2022-0128     vim is vulnerable to Out-of-bounds Read
CVE-2021-46059     A Pointer Dereference vulnerability exists in Vim 8.2.3883 via the vim_regexec_multi function at regexp.c, which causes a denial of service.
CVE-2021-4193     vim is vulnerable to Out-of-bounds Read
CVE-2021-4192     vim is vulnerable to Use After Free
CVE-2021-4187     vim is vulnerable to Use After Free
CVE-2021-4173     vim is vulnerable to Use After Free
CVE-2021-4166     vim is vulnerable to Out-of-bounds Read
CVE-2021-4136     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-4069     vim is vulnerable to Use After Free
CVE-2021-4019     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3984     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3974     vim is vulnerable to Use After Free
CVE-2021-3973     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3968     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3928     vim is vulnerable to Use of Uninitialized Variable
CVE-2021-3927     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3903     vim is vulnerable to Heap-based Buffer Overflow
CVE-2021-3875     vim is vulnerable to Heap-based Buffer Overflow 

[ken@…]

Replying to Douglas R. Reno:

Updating vim again at the next LFS update would be a good idea.

On 10/4/21 08:48, Alan Coopersmith wrote:
> On 9/30/2021 7:39 PM, Alan Coopersmith wrote:

[snip]

CVE-2021-46059 A Pointer Dereference vulnerability exists in Vim 8.2.3883 via the vim_regexec_multi function at regexp.c, which causes a denial of service.

CVE-2021-46059 has been rejected.

[ken@…]

It turns out that 8.2.4383 also contained a security update (applied in 8.2.4359) for a crash when repeatedly using :retab. ​https://github.com/vim/vim/commit/6e28703a8e41f775f64e442c5d11ce1ff599aa3f Not yet analyzed at NVD.

[Xi Ruoyao]

I'll update to 8.2.4489 for 4 CVEs (2022-0685,0714,0696,0729). Not sure how severe they are: their CVSS score are high but the upstream claims the worst thing could happen is a crash.

[ken@…]

Replying to Xi Ruoyao:

I'll update to 8.2.4489 for 4 CVEs (2022-0685,0714,0696,0729). Not sure how severe they are: their CVSS score are high but the upstream claims the worst thing could happen is a crash.

We've labelled application crashes, as well as lack of information on the consequences or severity, as High.

[Xi Ruoyao]

Replying to ken@…:

Replying to Xi Ruoyao:

I'll update to 8.2.4489 for 4 CVEs (2022-0685,0714,0696,0729). Not sure how severe they are: their CVSS score are high but the upstream claims the worst thing could happen is a crash.

We've labelled application crashes, as well as lack of information on the consequences or severity, as High.

SA 11.1-001 published with severity High.

[Xi Ruoyao]

CVE-2022-0943 is published with 8.4 HIGH.

[Xi Ruoyao]

CVE-2022-0943 fixed at f7ac150c8. Leave this assigned for SA.

[Xi Ruoyao]

SA 11.1-010 issued.

[Xi Ruoyao]

• CVE-2022-1154: Use after free in utf_ptr2char in GitHub repository vim/vim prior to 8.2.4646. (CVSS2 7.5 HIGH)
• CVE-2022-1160: heap buffer overflow in get_one_sourceline in GitHub repository vim/vim prior to 8.2.4647. (CVSS2 6.8 MEDIUM)

[Bruce Dubbs]

I'll update vim next week at my bi-monthly update.

[Xi Ruoyao]

• CVE-2022-1381: global heap buffer overflow in skip_range in GitHub repository vim/vim prior to 8.2.4763. (CVSS2 6.8 MEDIUM)

[Bruce Dubbs]

I have vim-8.2.4814 ready for inclusion in the next update. I plan on a full update of current tickets on April 30.

[Xi Ruoyao]

SA 11.1-037 issued.

[Xi Ruoyao]

• CVE-2022-1616: Use after free in append_command in GitHub repository vim/vim prior to 8.2.4895. This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution (6.8 MEDIUM)
• CVE-2022-1620: NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 in GitHub repository vim/vim prior to 8.2.4901. NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 allows attackers to cause a denial of service (application crash) via a crafted input. (5.0 MEDIUM)
• CVE-2022-1621: Heap buffer overflow in vim_strncpy find_word in GitHub repository vim/vim prior to 8.2.4919. This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution (6.8 MEDIUM)
• CVE-2022-1629: Buffer Over-read in function find_next_quote in GitHub repository vim/vim prior to 8.2.4925. This vulnerabilities are capable of crashing software, Modify Memory, and possible remote execution (6.8 MEDIUM)
• CVE-2022-1674: NULL Pointer Dereference in function vim_regexec_string at regexp.c:2733 in GitHub repository vim/vim prior to 8.2.4938. NULL Pointer Dereference in function vim_regexec_string at regexp.c:2733 allows attackers to cause a denial of service (application crash) via a crafted input. (4.3 MEDIUM)

I'm going to build LFS for my old system (for testing latest Mesa with crocus, mainly) so I can update vim BTW.

[Xi Ruoyao]

• CVE-2022-1733: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.4968. (4.6 MEDIUM)
• CVE-2022-1735: Classic Buffer Overflow in GitHub repository vim/vim prior to 8.2.4969. (6.8 MEDIUM)
• CVE-2022-1769: Buffer Over-read in GitHub repository vim/vim prior to 8.2.4974. (4.6 MEDIUM)
• CVE-2022-1771: Uncontrolled Recursion in GitHub repository vim/vim prior to 8.2.4975. (4.3 MEDIUM)
• CVE-2022-1785: Out-of-bounds Write in GitHub repository vim/vim prior to 8.2.4977. (4.6 MEDIUM)
• CVE-2022-1796: Use After Free in GitHub repository vim/vim prior to 8.2.4979. (6.8 MEDIUM)

[Xi Ruoyao]

Fixed at r11.1-129-ge6e8f0047. Vim left assigned for SA.

[Xi Ruoyao]

SA 11.1-053 done.

[Xi Ruoyao]

Now 9.0.0001.

[Bruce Dubbs]

Replying to Xi Ruoyao:

Now 9.0.0001.

It's up to 9.0.0006 already. Seems to be some changes in scripting.

​https://github.com/brammool/vim9/blob/master/README.md

The date of this file is about 2 months ago.

[Xi Ruoyao]

Now 9.1.

[Douglas R. Reno]

heap-buffer-overflow with visual mode in Vim < 9.1.1003
=======================================================
Date: 11.01.2025
Severity: Medium
CVE: CVE-2025-22134
CWE: Heap-based Buffer Overflow (CWE-122)

When switching to other buffers using the :all command and visual mode
still being active, this may cause a heap-buffer overflow, because Vim
does not properly end visual mode and therefore may try to access
beyond the end of a line in a buffer.

In Patch 9.1.1003 Vim will correctly reset the visual mode before
opening other windows and buffers and therefore fix this bug.  In
addition it does verify that it won't try to access a position if the
position is greater than the corresponding buffer line.

Impact is medium since the user must have switched on visual mode when
executing the :all ex command.

The issue has been fixed as of Vim patch v9.1.1003

The Vim project would like to thank github user gandalf4a for reporting
this issue.

References:
https://github.com/vim/vim/commit/c9a1e257f1630a0866447e53a564f7ff96a80ead
https://github.com/vim/vim/security/advisories/GHSA-5rgf-26wj-48v8

[Douglas R. Reno]

segmentation fault in win_line() in Vim < 9.1.1043
==================================================
Date: 20.01.2025
Severity: Medium
CVE: CVE-2025-24014
CWE: Out-of-bounds Write (CWE-787)

In silent Ex mode (-s -e), Vim typically doesn't show a screen and just
operates silently in batch mode. However, it is still possible to
trigger the function that handles the scrolling of a gui version of Vim
by feeding some binary characters to Vim. The function that handles the
scrolling however may be triggering a redraw, which will access the
ScreenLines pointer, even so this variable hasn't been allocated
(since there is no screen).

In Patch 9.1.1043 Vim will therefore skip the redraw attempt, by testing
whether the ScreenLines pointer is NULL.

Impact is medium since the user must intentionally and explicitly feed
some binary data to Vim in ex mode.

[Douglas R. Reno]

SA-12.2-073 issued for CVE-2025-24014

[Joe Locash]

A heap use-after-free was found in str_to_reg() in Vim < 9.1.1115
==================================================================
Date: 16.02.2025
Severity: Medium
CVE: *not yet assigned
CWE: Use-after-free (CWE-416)

Vim allows to redirect screen messages using the `:redir` ex command to
register, variables and files. It also allows to show the contents of
registers using the `:registers` or `:display` ex command.

When redirecting the output of `:display` to a register, Vim will free
the register content before storing the new content in the
register. Now when redirecting the `:display` command to a register that
is being displayed, Vim will free the content while shortly afterwards
trying to access it, which leads to a use-after-free.

Vim pre 9.1.1115 checks in the ex_display() function, that it does not
try to redirect to a register while displaying this register at the same
time. However this check is not complete, and so Vim does not check the
`+` and `*` registers (which typically donate the X11/clipboard
registers, and when a clipboard connection is not possible will fall
back to use register 0 instead.

In Patch 9.1.1115 Vim will therefore skip outputting to register zero
when trying to redirect to the clipboard registers `*` or `+`.

Impact is medium since this is a rather unusual situation and a user
must explicitly run this command.

The Vim project would like to thank github user @fizz-is-on-the-way
for reporting this issue.

The issue has been fixed as of Vim patch v9.1.1115

References:
https://github.com/vim/vim/commit/c0f0e2380e5954f4a52a131bf6b8
https://github.com/vim/vim/security/advisories/GHSA-63p5-mwg2-787v

[Xi Ruoyao]

I'll do it for LFS.

[Douglas R. Reno]

SA-12.2-087 issued for CVE-2025-26603 (the above heap use-after-free)

[Joe Locash]

potential code execution with tar.vim and special crafted tar files
===================================================================
Date: 02.03.2025
Severity: High
CVE: <not-yet-assigned>
CWE: Improper Input Validation (CWE-20)

Vim is distributed with the tar.vim plugin, that allows easy editing and
viewing of (compressed or uncompressed) tar files.

Since commit 129a8446d23cd9cb4445fcfea259cba5e0487d29
(Nov 11, 2024 runtime(tar): Update tar.vim to support permissions), the
tar.vim plugin uses the ":read <fname>" ex command line to append
<fname> below the cursor position, however the <fname> is not sanitized
and is taken literaly from the tar archive. This allows to execute shell
commands via special crafted tar archives. Whether this really happens,
depends on the shell being used ('shell' option, which is set using
$SHELL).

Impact is **high** but a user must be convinced to edit such a file
using Vim which will reveal the filename, so a careful user may suspect
some strange things going on.

The Vim project would like to thank RyotaK (GMO Flatt Security Inc) for
reporting this issue.

The issue has been fixed as of Vim patch v9.1.1164

[Commit](https://github.com/vim/vim/commit/334a13bff78aa0ad206bc436885f63e3a0bab399)
[Github Advisory](https://github.com/vim/vim/security/advisories/GHSA-wfmf-8626-q3r3)

[Bruce Dubbs]

As of last night we were at v9.1.1163. :(

[Douglas R. Reno]

SA-12.2-097 issued for CVE-2025-27423 (the code execution issue viewing crafted tar files). This should be the last security advisory for 12.2

[Joe Locash]

potential data loss with zip.vim and special crafted zip files
==============================================================
Date: 12.03.2025
Severity: Medium
CVE: *not-yet-assigned*
CWE: Improper Neutralization of Argument Delimiters in a Command
     ('Argument Injection') (CWE-88)

# Summary
potential data loss with zip.vim and special crafted zip files

# Description
Vim is distributed with the zip.vim plugin, that allows easy editing and
viewing of zip archives.

To view and extract zip files, vim uses the unzip(1) command, usually
provided by Info-ZIP[1], latest version on Debian is 6.0 from April
2009.

If an attacker creates an archive which contains a file `-d/tmp`, and a
Vim user views such a file and tries to extract such filename from the
archive, Vim will essentially run the following unzip command:

unzip -o <archive.zip> member-filename

However, since the member-filename is called `-d/tmp`, this is seen by
the unzip command as an additional argument and it therefore happily
extracts the whole archive into the mentioned directory, overwriting
existing files because of the `-o`.

Unfortunately, the latest released unzip version does not support `--`
as and end-of-argument marker, so we cannot use this to mark the
beginning of the member-files for unzip. Well, apparently there exists
some 6.10 beta release[2], that hasn't made it to an official release
yet which supports the use of the `--` marker since 2010 (but this isn't
widely known).

Therefore, Vim will try to work-around it by using the `[-]` glob when a
filename starts with a `-` to protect unzip from parsing the filename as
an argument, which is just an ugly work-around.

# Impact
Impact is **moderate** because a user must be made to view such an 
archive with Vim and then press 'x' to extract such a strange filename.

The Vim project would like to thank @Ry0taK (GMO Flatt Security Inc) and
@takumi-san-ai for reporting this issue.

The issue has been fixed as of Vim patch v9.1.1198

[1]: http://www.info-zip.org/pub/infozip/
[2]: http://antinode.info/ftp/info-zip/unzip610c25c.zip

[Commit](https://github.com/vim/vim/commit/f209dcd3defb95bae21b2740910e6aa7bb940531)
[Github Advisory](https://github.com/vim/vim/security/advisories/GHSA-693p-m996-3rmf)

[Douglas R. Reno]

Two security vulnerabilities were reported as fixed today:

path traversal issue with tar.vim and special crafted tar archives in Vim < 9.1.1552
====================================================================================
Date: 15.07.2025
Severity: Low
CVE: CVE-2025-53905
CWE: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)

### Summary
A path traversal issue in Vim’s tar.vim plugin can allow overwriting of
arbitrary files when opening specially crafted tar archives.

### Description
Vim includes the tar.vim plugin, which enables viewing and editing of files
within tar (and compressed tar) archives.

An attacker can create a tar archive that contains member files with relative
paths (e.g., ../../somefile). If such an archive is opened in Vim, and the user
saves one of these malicious files, Vim may overwrite files outside the
intended working directory.

Exploitation requires several conditions:
- The user opens a specially crafted archive in Vim.
- The user selects and attempts to edit one of the files within the archive.
- Vim writes the file back to disk using :w!.

Only after all these steps are performed would Vim overwrite an existing file
on disk.

**Note**:
- Vim does display the full path to be written, so a careful user may notice
  suspicious behavior.
- Standard tar utilities typically do not extract such paths and will warn or
  skip them. This issue only affects Vim's internal handling, not the tar tool
  itself.


### Proof of Concept
As a Proof of Concept, the following code crafts a malicious archive:
```
echo pwned > pwn; tar --transform='s|^|/etc/ax-|' -cf evil.tar pwn
```
If the file contained in the evil.tar archive is edited through vim, typing
':w' to save it will create /etc/ax-pwn on the host filesystem (provided that
the user has sufficient permissions to write into the /etc directory.

### Impact
Impact is **low** because this exploit requires direct user interaction:

However successfully exploitation can lead to overwritint sensitive files or
placing executable code in privileged locations, depending on the permissions
of the process editing the archive.

The victim must edit such a file using Vim which will reveal the filename
and the file content, a careful user may suspect some strange things going on.
Successful exploitation could results in the ability to execute
arbitrary commands on the underlying operating system.

The Vim project would like to thank @ax for reporting this issue.

The issue has been fixed as of Vim patch v9.1.1552

[Commit](https://github.com/vim/vim/commit/87757c6b0a4b2c1f71c72ea8e1438b8fb116b239)
[Github Advisory](https://github.com/vim/vim/security/advisories/GHSA-74v4-f3x9-ppvr)
Liebe Grüße
Christian

and

path traversal issue with zip.vim and special crafted zip archives in Vim < v9.1.1551
=====================================================================================
Date: 15.07.2025
Severity: Low
CVE: CVE-2025-53906
CWE: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)

### Summary
A path traversal issue in Vim’s zip.vim plugin can allow overwriting of
arbitrary files when opening specially crafted zip archives.

### Description
Vim includes the zip.vim plugin, which enables viewing and editing of files
within zip archives.

An attacker can create a zip archive that contains member files with relative
paths (e.g., ../../somefile). If such an archive is opened in Vim, and the user
saves one of these malicious files, Vim may overwrite files outside the
intended working directory.

Exploitation requires several conditions:
- The user opens a specially crafted archive in Vim.
- The user selects and attempts to edit one of the files within the archive.
- Vim writes the file back to disk using :w!.

Only after all these steps are performed would Vim overwrite an existing file
on disk.

**Note**:
- Vim does display the full path to be written, so a careful user may notice
  suspicious behavior.
- Standard zip utility typically do not extract such paths and will warn or
  skip them. This issue only affects Vim's internal handling, not the zip tool
  itself.


### Proof of Concept
As a Proof of Concept, the following code crafts a malicious archive:
```python
import zipfile
import os
zip_path='evil.zip'
fname='file'
arcname='/etc/ax-pwn'
arcname='../../../../etc/ax-pwn'
with open(fname, 'w') as f:
	f.write(f"pwned\n")
with zipfile.ZipFile(zip_path, 'w') as zipf:
	zipf.write(fname, arcname)
print(f"Created {zip_path}" )
```
If the file contained in the evil.zip archive is edited through vim, typing
':w' to save it will create /etc/ax-pwn on the host filesystem (provided that
the user has sufficient permissions to write into the /etc directory.

### Impact
Impact is **low** because this exploit requires direct user interaction:

However successfully exploitation can lead to overwriting sensitive files or
placing executable code in privileged locations, depending on the permissions
of the process editing the archive.

The victim must edit such a file using Vim which will reveal the filename
and the file content, a careful user may suspect some strange things going on.
Successful exploitation could results in the ability to execute
arbitrary commands on the underlying operating system.

The Vim project would like to thank @ax for reporting this issue.

The issue has been fixed as of Vim patch v9.1.1551

[Commit](https://github.com/vim/vim/commit/586294a04179d855c3d1d4ee5ea83931963680b8)
[Github Advisory](https://github.com/vim/vim/security/advisories/GHSA-r2fw-9cw4-mj86)


Liebe Grüße
Christian
-- 
Wir suchen die Wahrheit, finden wollen wir sie aber nur dort, wo es
uns beliebt.
		-- Marie von Ebner-Eschenbach

We'll want to update to at least 9.1.1552 to fix these, and they do affect editors in particular since we open up TAR files using Vim occasionally.