vim is vulnerable to Heap-based Buffer Overflow Reference: https://huntr.dev/bounties/5cdbc168-6ba1-4bc2-ba6c-28be12166a53 Upstream patch: https://github.com/vim/vim/commit/35a319b77f897744eec1155b736e9372c9c5575f
Created vim tracking bugs for this issue: Affects: fedora-all [bug 2014662]
marking hosted services affected (low) / delegated solely for presence of affected code.
Flaw summary: In vim's undo.c, u_save_line() looks like: u_save_line(undoline_T *ul, linenr_T lnum) { char_u *line = ml_get(lnum); if (curbuf->b_ml.ml_line_len == 0) { ul->ul_len = 1; ul->ul_line = vim_strsave((char_u *)""); } else { // This uses the length in the memline, thus text properties are // included. ul->ul_len = curbuf->b_ml.ml_line_len; ul->ul_line = vim_memsave(line, ul->ul_len); } return ul->ul_line == NULL ? FAIL : OK; } This flaw involves the line ul->ul_line = vim_memsave(line, ul->ul_len); . Specifically, ul->ul_len can be an incorrect length of `line` if `lnum` is out of range. This causes an out-of-bounds read in vim_memsave() -> mch_memmove() because although the new allocation size is ok, the memory read operation can be an out-of-bounds read of memory pointed to by `p` in: vim_memsave(char_u *p, size_t len) { char_u *ret = alloc(len); if (ret != NULL) mch_memmove(ret, p, len); return ret; } because the `len` parameter (ul->ul_len) doesn't match the proper `len` for `lnum`. This does not reproduce, nor does it affect versions of vim shipped in any Red Hat Enterprise Linux version because the vulnerable code was introduced in a newer version of vim than those shipped.