VYPR
Unrated severityNVD Advisory· Published Jul 1, 2022· Updated Aug 3, 2024

Heap-based Buffer Overflow in vim/vim

CVE-2022-2264

Description

A heap-based buffer overflow in Vim before version 9.0 allows arbitrary code execution via crafted input.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A heap-based buffer overflow in Vim before version 9.0 allows arbitrary code execution via crafted input.

Vulnerability

Heap-based buffer overflow in GitHub repository vim/vim prior to version 9.0. The flaw exists in the do_put() function and is triggered during a put command in visual mode with selection=exclusive and leading tab characters. The overflow occurs when calculating the length of inserted spaces without proper bounds checking [3].

Exploitation

An attacker requires the ability to supply a crafted text file or input that triggers the vulnerable code path. The user must open the file in Vim and execute a put command (e.g., p) in visual mode with selection=exclusive and a line starting with a tab character. No authentication is needed beyond local file access [3].

Impact

Successful exploitation leads to a heap-based buffer overflow, which can be leveraged to cause a denial of service or potentially achieve arbitrary code execution in the context of the Vim process. This could result in information disclosure, data corruption, or full system compromise depending on the user's privileges [1][2].

Mitigation

Fixed in Vim version 9.0 (patch 9.0.0011). Users should upgrade to Vim 9.0 or later. Gentoo users can upgrade to >=app-editors/vim-9.0.0060 [4]. No known workaround is available; upgrading is the recommended action [1][2][3].

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

39

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Missing length adjustment in `do_put()` when spacing is not used, causing `totlen` to exceed the actual buffer size and leading to a heap out-of-bounds read."

Attack vector

An attacker can trigger a heap-based buffer overflow by crafting a file and using the put command (`p`) in visual mode with specific settings (`selection=exclusive`) and a tab character. The test case shows the sequence: open a buffer, set `selection=exclusive`, insert a tab, set a mark, then execute `p` (put) twice with Ctrl-Q prefix [ref_id=1]. This causes `do_put()` to read beyond the end of the line, leading to a heap buffer overflow [CWE-122].

Affected code

The vulnerability is in the `do_put()` function in Vim's source code. The patch modifies the logic that handles spacing when inserting text with the put command, specifically adding an `else` branch to adjust `totlen` when spaces are not used [patch_id=d25f003].

What the fix does

The patch adds an `else` clause to the spacing logic in `do_put()` so that when spaces are not actually used (the condition for using them was false), `totlen` is decremented by the number of unused spaces. Without this fix, `totlen` remained too large, causing subsequent operations to read beyond the end of the allocated line buffer. The fix ensures the length tracking stays consistent with the actual data written [patch_id=d25f003].

Preconditions

  • configVim must be configured with `selection=exclusive`
  • inputThe attacker must provide a file containing a tab character and trigger the put command in visual mode
  • inputThe attacker needs to execute the put command twice in sequence

Reproduction

The test case from the patch provides reproduction steps: `edit! SomeNewBuffer`, `set selection=exclusive`, `exe "norm o\t"`, `m0`, `sil! norm \u0011p\u0011p` [ref_id=1]. This opens a new buffer, sets exclusive selection, inserts a tab, sets a mark, and executes the put command twice with Ctrl-Q prefix.

Generated on May 28, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.