hitoshura25/cvefixes huggingface dataset:
CVE-2023-4734 (C, published 2023-09-02T18:15Z)
Description: value: Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1846.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
src/ex_docmd.c
src/testdir/test_functions.vim
src/version.c
Commit message: patch 9.0.1846: [security] crash in fullcommand

Problem:  crash in fullcommand
Solution: Check for typeval correctly

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
    name = argvars[0].vval.v_string;

Fixed code:
    name = tv_get_string(&argvars[0]);
func Test_fullcommand()
  " this used to crash vim
  call assert_equal('', fullcommand(10))
endfunc

/**/
    1846,
CVE-2023-4735 (C, published 2023-09-02T18:15Z)
Description: value: Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1847.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/vim/vim
Files changed:
src/ops.c
src/version.c
Commit message: patch 9.0.1847: [security] potential oob write in do_addsub()

Problem:  potential oob write in do_addsub()
Solution: don't overflow buf2, check size in for loop()

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
	    for (i = 0; bit > 0; bit--)

Fixed code:
	    for (i = 0; bit > 0 && i < (NUMBUFLEN - 1); bit--)
/**/
    1847,
CVE-2023-4738 (C, published 2023-09-02T20:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/vim/vim
Files changed:
src/ex_cmds.c
src/regexp.c
src/testdir/crash/vim_regsub_both
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1848: [security] buffer-overflow in vim_regsub_both()

Problem:  buffer-overflow in vim_regsub_both()
Solution: Check remaining space

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
	    if (eval_result[nested] != NULL)
  let opts = #{wait_for_ruler: 0}

Fixed code:
		if (new_start_len - copy_len < sublen)
		    sublen = new_start_len - copy_len - 1;

	    if (eval_result[nested] != NULL &&
		    STRLEN(eval_result[nested]) < destlen)
fu R()
sil!norm0z=
endf
cal R()
s/\%')/\=R()
d
no0 normyynore sm:vs0@vvvvvvvvvvse()dir(¼Xtest=csd{so88
vs
0scr
so
  let opts = #{wait_for_ruler: 0, rows: 20}
func Test_crash2()
  " The following used to crash Vim
  let opts = #{wait_for_ruler: 0, rows: 20}
  let args = ' -u NONE -i NONE -n -e -s -S '
  let buf = RunVimInTerminal(args .. ' crash/vim_regsub_both', opts)
  call VerifyScreenDump(buf, 'Test_crash_01', {})
  exe buf .. "bw!"
endfunc

/**/
    1848,
CVE-2023-4750 (C, published 2023-09-04T14:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.1857.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/vim/vim
Files changed:
src/main.c
src/quickfix.c
src/testdir/crash/bt_quickfix_poc
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1857: [security] heap-use-after-free in is_qf_win()

Problem:  heap-use-after-free in is_qf_win()
Solution: Check buffer is valid before accessing it

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
		if (wp->w_buffer == NULL)
    if (bt_quickfix(win->w_buffer))
  " let opts = #{wait_for_ruler: 0, rows: 20, cmd: 'sh'}
  let args = 'bash'
  let buf = RunVimInTerminal(args, opts)
    \ '  && echo "crash 1: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 50)
  call assert_equal(['crash 1: [OK]', 'crash 2: [OK]', 'crash 3: [OK]'],
    \ getline(1, '$'))

Fixed code:
		if (wp->w_buffer == NULL || !buf_valid(wp->w_buffer))
    if (buf_valid(win->w_buffer) && bt_quickfix(win->w_buffer))
comman!-narg=* Xexpr <mods>lex<args>
auto BufReadPre * exe"sn" ..expand("<abuf>") 
fu Xautocmd_changelist()
cal writefile(['Xtestfile2:4:4'],'Xerr')
  sil! edi Xerr
Xexpr 'Xtestfile:4:4'
endf
call Xautocmd_changelist()
call Xautocmd_changelist()
  if !executable('sh')
    throw 'Skipped: sh not executable!'
  endif
  let buf = RunVimInTerminal('sh', opts)
    \ '  && echo "crash 1: [OK]" > X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 50)
  call TermWait(buf, 50)
  call TermWait(buf, 100)
  let file = 'crash/bt_quickfix_poc'
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  && echo "crash 4: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  " clean up
  call delete('Xerr')

  " This test takes a bit longer
  call TermWait(buf, 200)
  call delete('Xerr')

  let expected = [
      \ 'crash 1: [OK]',
      \ 'crash 2: [OK]',
      \ 'crash 3: [OK]',
      \ 'crash 4: [OK]',
      \ ]

  call assert_equal(expected, getline(1, '$'))
/**/
    1857,
CVE-2023-4751 (C, published 2023-09-03T19:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1331.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-122 \u2014 Heap-based Buffer Overflow
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Repository: https://github.com/vim/vim
Files changed:
src/buffer.c
src/testdir/test_visual.vim
src/version.c
Commit message: patch 9.0.1331: illegal memory access when using :ball in Visual mode

Problem:    Illegal memory access when using :ball in Visual mode.
Solution:   Stop Visual mode when using :ball. (Pavel Mayorov, closes #11923)


Vulnerable code:

Fixed code:
    // Stop Visual mode, the cursor and "VIsual" may very well be invalid after
    // switching to another buffer.
    reset_VIsual_and_resel();

" Check fix for the heap-based buffer overflow bug found in the function
" utfc_ptr2len and reported at
" https://huntr.dev/bounties/ae933869-a1ec-402a-bbea-d51764c6618e
func Test_heap_buffer_overflow()
  enew
  set updatecount=0

  norm R0
  split other
  norm R000
  exe "norm \<C-V>l"
  ball
  call assert_equal(getpos("."), getpos("v"))
  call assert_equal('n', mode())
  norm zW

  %bwipe!
  set updatecount&
endfunc


/**/
    1331,
CVE-2023-4752 (Other, published 2023-09-04T14:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.1858.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/vim/vim
Files changed:
src/insexpand.c
src/testdir/crash/poc_tagfunc.vim
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1858: [security] heap use after free in ins_compl_get_exp()

Problem:  heap use after free in ins_compl_get_exp()
Solution: validate buffer before accessing it

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
	    if (type == 0 || type == CTRL_X_PATH_PATTERNS)

  call delete('Xerr')

Fixed code:
	    if (buf_valid(st.ins_buf) && (type == 0 || type == CTRL_X_PATH_PATTERNS))
fu Tagfunc(t,f,o)
  bw
endf
set tagfunc=Tagfunc
n0
sil0norm0i
  let file = 'crash/poc_tagfunc.vim'
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  || echo "crash 5: [OK]" >> X_crash1_result.txt' .. "\<cr>")

  call TermWait(buf, 100)

      \ 'crash 5: [OK]',
/**/
    1858,
CVE-2023-4781 (C, published 2023-09-05T19:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1873.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-122 \u2014 Heap-based Buffer Overflow
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Repository: https://github.com/vim/vim
Files changed:
src/ex_cmds.c
src/testdir/test_crash.vim
src/version.c
src/window.c
Commit message: patch 9.0.1873: [security] heap-buffer-overflow in vim_regsub_both

Problem:  heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
		    // safety check
		    if (nmatch < 0)
			goto skip;
  " using || because this poc causes vim to exit with exitstatus != 0
  let file = 'crash/vim_regsub_both_poc'
  let args = printf(cmn_args, vim, file)
  " using || because this poc causes vim to exit with exitstatus != 0
  call term_sendkeys(buf, args ..
    \ '  && echo "crash 7: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 1000)

      \ 'crash 7: [OK]',
/**/
    1873,
    if (text_or_buf_locked())
    {
	beep_flush();
	return;
    }
CVE-2023-48231 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/vim/vim
Files changed:
src/testdir/test_crash.vim
src/version.c
src/window.c
Commit message: patch 9.0.2106: [security]: Use-after-free in win_close()

Problem:  [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it

If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.

Add a test to trigger ASAN in CI

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
func Test_crash1_2()
  CheckNotBSD
  CheckExecutable dash

  " The following used to crash Vim
  let opts = #{cmd: 'sh'}
  let vim  = GetVimProg()
  let result = 'X_crash1_1_result.txt'

  let buf = RunVimInTerminal('sh', opts)

  let file = 'crash/poc1'
  let cmn_args = "%s -u NONE -i NONE -n -e -s -S %s -c ':qa!'"
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  && echo "crash 1: [OK]" > '.. result .. "\<cr>")
  call TermWait(buf, 150)

  " clean up
  exe buf .. "bw!"

  exe "sp " .. result

  let expected = [
      \ 'crash 1: [OK]',
      \ ]

  call assert_equal(expected, getline(1, '$'))
  bw!

  call delete(result)
endfunc

/**/
    2106,
	    if (!win_valid(win))
		return FAIL;
CVE-2023-48232 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. 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. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-755 \u2014 Improper Handling of Exceptional Conditions
The product does not handle or incorrectly handles an exceptional condition.
Repository: https://github.com/vim/vim
Files changed:
src/move.c
src/testdir/test_scroll_opt.vim
src/version.c
Commit message: patch 9.0.2107: [security]: FPE in adjust_plines_for_skipcol

Problem:  [security]: FPE in adjust_plines_for_skipcol
Solution: don't divide by zero, return zero

Prevent a floating point exception when calculating w_skipcol (which can
happen with a small window when the number option is set and cpo+=n).

Add a test to verify

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
    if (wp->w_skipcol >= width)
	return (wp->w_skipcol - width) / (width + win_col_off2(wp)) + 1;

Fixed code:
    int w2 = width + win_col_off2(wp);
    if (wp->w_skipcol >= width && w2 > 0)
	return (wp->w_skipcol - width) / w2 + 1;
" Division by zero, shouldn't crash
func Test_smoothscroll_crash()
  CheckScreendump

  let lines =<< trim END
      20 new
      vsp
      put =repeat('aaaa', 20)
      set nu fdc=1  smoothscroll cpo+=n
      vert resize 0
      exe "norm! 0\<c-e>"
  END
  call writefile(lines, 'XSmoothScrollCrash', 'D')
  let buf = RunVimInTerminal('-u NONE -S XSmoothScrollCrash', #{rows: 12, cols:40})
  call term_sendkeys(buf, "2\<C-E>\<C-L>")

  call StopVimInTerminal(buf)
endfunc

/**/
    2107,
CVE-2023-48233 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. 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 in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
runtime/doc/change.txt
runtime/doc/cmdline.txt
runtime/doc/tags
src/ex_cmds.c
src/testdir/test_substitute.vim
src/version.c
Commit message: patch 9.0.2108: [security]: overflow with count for :s command

Problem:  [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large

If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.

Adds a test with INT_MAX as count and verify it correctly fails.

It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
*change.txt*    For Vim version 9.0.  Last change: 2023 Sep 19
							*E939*
			[count] must be a positive number.  Also see
			|cmdline-ranges|.
*cmdline.txt*   For Vim version 9.0.  Last change: 2023 May 20

Fixed code:
*change.txt*    For Vim version 9.0.  Last change: 2023 Nov 15
							*E939* *E1510*
			[count] must be a positive number (max 2147483647)
			Also see |cmdline-ranges|.
*cmdline.txt*   For Vim version 9.0.  Last change: 2023 Nov 15
		(see |E1510|)
E1510	change.txt	/*E1510*
	else if (i >= INT_MAX)
	{
	    char	buf[20];
	    vim_snprintf(buf, sizeof(buf), "%ld", i);
	    semsg(_(e_val_too_large), buf);
	    return;
	}
  call assert_fails('s/./b/2147483647', 'E1510:')
/**/
    2108,
CVE-2023-48234 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
src/normal.c
src/testdir/test_normal.vim
src/version.c
Commit message: patch 9.0.2109: [security]: overflow in nv_z_get_count

Problem:  [security]: overflow in nv_z_get_count
Solution: break out, if count is too large

When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
	{
	    if (n > LONG_MAX / 10)
	    {
		clearopbeep(cap->oap);
		break;
	    }
	}
func Test_normal34_zet_large()
  " shouldn't cause overflow
  norm! z9765405999999999999
endfunc

/**/
    2109,
CVE-2023-48235 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an
overflow. Ironically 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 in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
src/ex_docmd.c
src/testdir/test_excmd.vim
src/version.c
Commit message: patch 9.0.2110: [security]: overflow in ex address parsing

Problem:  [security]: overflow in ex address parsing
Solution: Verify that lnum is positive, before substracting from
          LONG_MAX

[security]: overflow in ex address parsing

When parsing relative ex addresses one may unintentionally cause an
overflow (because LONG_MAX - lnum will overflow for negative addresses).

So verify that lnum is actually positive before doing the overflow
check.

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
		    if (n >= LONG_MAX - lnum)

Fixed code:
		    if (lnum >= 0 && n >= LONG_MAX - lnum)
" catch address lines overflow
func Test_ex_address_range_overflow()
  call assert_fails(':--+foobar', 'E492:')
endfunc
/**/
    2110,
CVE-2023-48236 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger
than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
src/misc1.c
src/testdir/test_spell.vim
src/version.c
Commit message: patch 9.0.2111: [security]: overflow in get_number

Problem:  [security]: overflow in get_number
Solution: Return 0 when the count gets too large

[security]: overflow in get_number

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

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
	    if (n > INT_MAX / 10)
		return 0;
func Test_z_equal_with_large_count()
  split
  set spell
  call setline(1, "ff")
  norm 0z=337203685477580
  set nospell
  bwipe!
endfunc

/**/
    2111,