[vim/vim] Memory leak (CWE-401) when ga_grow() fails in expand_pattern_in_buf() (Issue #20667)

6 views

Skip to first unread message

jiejiaodedengdai

unread,

1:36 AM (12 hours ago) 1:36 AM

to vim/vim, Subscribed

jiejiaodedengdai created an issue (vim/vim#20667)

Steps to reproduce

Locate function expand_pattern_in_buf() in src/cmdexpand.c
Trigger the search completion logic to call concat_pattern_with_buffer_match() successfully to allocate the match pointer.
Force an out-of-memory state to make ga_grow(&ga, 1) return FAIL during array expansion.
The code jumps to the cleanup label directly without freeing the allocated match buffer.
ga_clear_strings() only frees existing entries inside the garray, the unadded match memory becomes unreachable and causes a permanent heap memory leak.
This path can be triggered remotely with specially crafted long search input.

Expected behaviour

When ga_grow() fails to expand the dynamic array, the temporarily allocated match pointer should be explicitly released with vim_free(match) before jumping to cleanup, to avoid heap memory leakage.

Version of Vim

Latest main branch

Environment

Operating system: Linux x86_64 (Ubuntu / Debian Server)

Logs and stack traces

Vulnerability Details
File path: src/cmdexpand.c
Memory allocation line: Line 5029
Risk line: Line 5052
Vulnerability Type: memory_leak (CWE-401 Missing Release of Memory after Effective Lifetime)
Vulnerability Description
The pointer match obtains successfully allocated heap memory at line 5029 via concat_pattern_with_buffer_match().
At line 5052, if ga_grow(&ga, 1) fails to expand the dynamic array due to insufficient memory (OOM), the program jumps directly to the cleanup label.
The cleanup logic only calls ga_clear_strings(&ga), which can only release memory pointers that have already been saved inside the garray. Since the newly allocated match pointer has not been added to the array, this heap memory will never be released, resulting in a permanent memory leak.
This is a partial path memory leak. Normal execution will hand over memory management to the garray normally. Only the OOM expansion failure path triggers leakage. Continuous repeated calls can cause slow remote DoS attacks, with no risk of arbitrary code execution.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

h_east

unread,

6:14 AM (7 hours ago) 6:14 AM

to vim/vim, Subscribed

h-east left a comment (vim/vim#20667)

Thanks for the report, but this leak does not exist in the current source.

On the ga_grow(&ga, 1) == FAIL path, match is freed before the jump to the
cleanup label:

if (match != NULL)
{
    if (ga_grow(&ga, 1) == FAIL)
    {
        VIM_CLEAR(match);   // vim_free(match); match = NULL;
        goto cleanup;
    }
    ((char_u **)ga.ga_data)[ga.ga_len++] = match;
    ...
}

VIM_CLEAR() calls vim_free() and sets the pointer to NULL, so the allocation
from concat_pattern_with_buffer_match() is released on exactly the OOM path you
describe. On the non-exacttext branch full_match is freed earlier as well.
There is no leak.

The line numbers in the report (allocation at 5029, ga_grow at 5052) also do
not match the current source: expand_pattern_in_buf() starts around line 5229
and the relevant ga_grow(&ga, 1) is around line 5369.

A note on process: per our SECURITY.md, please report security issues privately
(vim-se...@googlegroups.com or a GitHub Security Advisory) rather than as a
public issue, and please carefully review AI-generated reports before submitting
them. This one is both publicly filed and incorrect on the point it raises.

Closing as invalid.

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward

0 new messages