hitoshura25/cvefixes huggingface dataset:
CVE-2023-0288 (C, published 2023-01-13T16:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189.
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/normal.c
src/testdir/test_fold.vim
src/version.c
Commit message: patch 9.0.1189: invalid memory access with folding and using "L"

Problem:    Invalid memory access with folding and using "L".
Solution:   Prevent the cursor from moving to line zero.


Vulnerable code:
		    --curwin->w_cursor.lnum;

Fixed code:
		    if (curwin->w_cursor.lnum > curwin->w_topline)
			--curwin->w_cursor.lnum;
func Test_indent_with_L_command()
  " The "L" command moved the cursor to line zero, causing the text saved for
  " undo to use line number -1, which caused trouble for undo later.
  new
  sil! norm 8RV{zf8=Lu
  bwipe!
endfunc

/**/
    1189,
CVE-2023-0433 (C, published 2023-01-21T15:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1225.
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/textformat.c
src/version.c
Commit message: patch 9.0.1225: reading past the end of a line when formatting text

Problem:    Reading past the end of a line when formatting text.
Solution:   Check for not going over the end of the line.


Vulnerable code:
		if (*(ml_get(lnum) + leader1_len) == NUL)

Fixed code:
    char_u  *lnum_line = NULL;
    int	    line_len = 0;

		if (lnum_line == NULL)
		{
		    lnum_line = ml_get(lnum);
		    line_len = (int)STRLEN(lnum_line);
		}
		if (line_len <= leader1_len)
/**/
    1225,
CVE-2023-0512 (Other, published 2023-01-30T16:15Z)
Description: value: Divide By Zero in GitHub repository vim/vim prior to 9.0.1247.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-369 \u2014 Divide By Zero
The product divides a value by zero.
Repository: https://github.com/vim/vim
Files changed:
src/move.c
src/testdir/dumps/Test_smoothscroll_zero_1.dump
src/testdir/dumps/Test_smoothscroll_zero_2.dump
src/testdir/test_scroll_opt.vim
src/version.c
Commit message: patch 9.0.1247: divide by zero with 'smoothscroll' set and a narrow window

Problem:    Divide by zero with 'smoothscroll' set and a narrow window.
Solution:   Bail out when the window is too narrow.


Vulnerable code:

Fixed code:
    if (width1 <= 0)
	return;  // no text will be displayed

> +0&#ffffff0@59
@60
@60
@60
@60
@60
|:+0&#ffffff0|s|i|l| |n|o|r|m| |^|W|^|N| @45
> @59
@60
@60
@60
@60
" this was dividing by zero
func Test_smoothscrol_zero_width()
  CheckScreendump

  let lines =<< trim END
      winsize 0 0
      vsplit
      vsplit
      vsplit
      vsplit
      vsplit
      sil norm H
      set wrap
      set smoothscroll
      set number
  END
  call writefile(lines, 'XSmoothScrollZero', 'D')
  let buf = RunVimInTerminal('-u NONE -i NONE -n -m -X -Z -e -s -S XSmoothScrollZero', #{rows: 6, cols: 60, wait_for_ruler: 0})
  call TermWait(buf, 3000)
  call VerifyScreenDump(buf, 'Test_smoothscroll_zero_1', {})

  call term_sendkeys(buf, ":sil norm \<C-V>\<C-W>\<C-V>\<C-N>\<CR>")
  call VerifyScreenDump(buf, 'Test_smoothscroll_zero_2', {})

  call StopVimInTerminal(buf)
endfunc

/**/
    1247,
CVE-2023-1127 (C, published 2023-03-01T19:15Z)
Description: value: Divide By Zero in GitHub repository vim/vim prior to 9.0.1367.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-369 \u2014 Divide By Zero
The product divides a value by zero.
Repository: https://github.com/vim/vim
Files changed:
src/move.c
src/testdir/test_window_cmd.vim
src/version.c
Commit message: patch 9.0.1367: divide by zero in zero-width window

Problem:    Divide by zero in zero-width window.
Solution:   Check the width is positive.


Vulnerable code:
	if (col > width2)
function Test_splitkeep_cmdwin_cursor_position()
endfunction
function Test_splitkeep_misc()
function Test_splitkeep_callback()
function Test_splitkeep_fold()
endfunction
function Test_splitkeep_status()
endfunction
function Test_new_help_window_on_error()
endfunction

Fixed code:
	if (col > width2 && width2 > 0)
func Test_splitkeep_cmdwin_cursor_position()
endfunc
func Test_splitkeep_misc()
func Test_splitkeep_callback()
func Test_splitkeep_fold()
endfunc
func Test_splitkeep_status()
endfunc
func Test_new_help_window_on_error()
endfunc

func Test_smoothscroll_in_zero_width_window()
  let save_lines = &lines
  let save_columns = &columns

  winsize 0 24
  set cpo+=n
  exe "noremap 0 \<C-W>n\<C-W>L"
  norm 000000
  set number smoothscroll
  exe "norm \<C-Y>"

  only!
  let &lines = save_lines
  let &columns = save_columns
  set cpo-=n
  unmap 0
  set nonumber nosmoothscroll
endfunc
/**/
    1367,
CVE-2023-1170 (C, published 2023-03-03T23:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376.
Severity: nan (CVSS v3 base score: 6.6)
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/register.c
src/testdir/test_put.vim
src/version.c
Commit message: patch 9.0.1376: accessing invalid memory with put in Visual block mode

Problem:    Accessing invalid memory with put in Visual block mode.
Solution:   Adjust the cursor column if needed.


Vulnerable code:
		if ((j < count - 1 || !shortline) && spaces)

Fixed code:
		if ((j < count - 1 || !shortline) && spaces > 0)
    // Make sure the cursor is not after the NUL.
    int len = (int)STRLEN(ml_get_curline());
    if (curwin->w_cursor.col > len)
    {
	if (cur_ve_flags == VE_ALL)
	    curwin->w_cursor.coladd = curwin->w_cursor.col - len;
	curwin->w_cursor.col = len;
    }

func Test_put_visual_block_mode()
  enew
  exe "norm 0R\<CR>\<C-C>V"
  sil exe "norm \<C-V>c	\<MiddleDrag>"
  set ve=all
  sil norm vz=p

  bwipe!
  set ve=
endfunc

/**/
    1376,
CVE-2023-1175 (C, published 2023-03-04T16:15Z)
Description: value: Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.
Severity: nan (CVSS v3 base score: 6.6)
Weakness: CWE-131 \u2014 Incorrect Calculation of Buffer Size
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
Repository: https://github.com/vim/vim
Files changed:
src/register.c
src/testdir/test_virtualedit.vim
src/version.c
Commit message: patch 9.0.1378: illegal memory access when using virtual editing

Problem:    Illegal memory access when using virtual editing.
Solution:   Make sure "startspaces" is not negative.


Vulnerable code:

Fixed code:
				if (bd.startspaces < 0)
				    bd.startspaces = 0;
func Test_edit_special_char()
  new
  se ve=all
  norm a0
  sil! exe "norm o00000\<Nul>k<a0s"

  bwipe!
  set virtualedit=
endfunc

/**/
    1378,
CVE-2023-1264 (Other, published 2023-03-07T22:15Z)
Description: value: NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1392.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/vim/vim
Files changed:
src/getchar.c
src/testdir/term_util.vim
src/testdir/test_ex_mode.vim
src/version.c
Commit message: patch 9.0.1392: using NULL pointer with nested :open command

Problem:    Using NULL pointer with nested :open command.
Solution:   Check that ccline.cmdbuff is not NULL.


Vulnerable code:
    int		c, c1;
		c1 = 0;
			    c1 = 1;
		    // this looks nice when typing a dead character map
			c1 = 1;
		if (c1 == 1)
		    if (State & MODE_CMDLINE)

Fixed code:
    int		c;
		int showing_partial = FALSE;
			    showing_partial = TRUE;
		    // This looks nice when typing a dead character map.
		    // There is no actual command line for get_number().
			    && get_cmdline_info()->cmdbuff != NULL
			showing_partial = TRUE;
		if (showing_partial)
		    if ((State & MODE_CMDLINE)
					&& get_cmdline_info()->cmdbuff != NULL)
" "no_clean" - if non-zero then remove "--clean" from the command
  if get(a:options, 'no_clean', 0)
    let cmd = substitute(cmd, '--clean', '', '')
  endif

" FIXME: this doesn't fail without the fix but hangs
func Skip_Test_open_command_state()
  " Tricky script that failed because State was not set properly
  let lines =<< trim END
      !ls 
      0scìi
      so! Xsourced
      set t_û0=0
      v/-/o
  END
  call writefile(lines, 'XopenScript', '')

  let sourced = ["!f\u0083\x02\<Esc>z=0"]
  call writefile(sourced, 'Xsourced', 'b')

  CheckRunVimInTerminal
  let buf = RunVimInTerminal('-u NONE -i NONE -n -m -X -Z -e -s -S XopenScript -c qa!', #{rows: 6, wait_for_ruler: 0, no_clean: 1})
  sleep 3

  call StopVimInTerminal(buf)
endfunc

/**/
    1392,
CVE-2023-1355 (C, published 2023-03-11T22:15Z)
Description: value: NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1402.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/vim/vim
Files changed:
src/testdir/test_vim9_class.vim
src/version.c
src/vim9class.c
Commit message: patch 9.0.1402: crash when using null_class

Problem:    Crash when using null_class.
Solution:   Give an error when trying to use a null class.


Vulnerable code:

Fixed code:
def Test_using_null_class()
  var lines =<< trim END
      @_ = null_class.member
  END
  v9.CheckDefExecAndScriptFailure(lines, ['E715:', 'E1363:'])
enddef

/**/
    1402,
    if (cl == NULL)
    {
	emsg(_(e_incomplete_type));
	return FAIL;
    }
CVE-2023-2426 (C, published 2023-04-29T22:15Z)
Description: value: Use of Out-of-range Pointer Offset in GitHub repository vim/vim prior to 9.0.1499.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-823 \u2014 Use of Out-of-range Pointer Offset
The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.
Repository: https://github.com/vim/vim
Files changed:
src/quickfix.c
src/search.c
src/testdir/test_matchfuzzy.vim
src/version.c
Commit message: patch 9.0.1499: using uninitialized memory with fuzzy matching

Problem:    Using uninitialized memory with fuzzy matching.
Solution:   Initialize the arrays used to store match positions.


Vulnerable code:
			col, NULL) > 0)
	    int_u	recursiveMatches[MAX_FUZZY_MATCHES];
	    int		recursiveScore = 0;
	    char_u	*next_char;

	    if (has_mbyte)
		next_char = str + (*mb_ptr2len)(str);
	    else
		next_char = str + 1;
 * Returns TRUE if 'pat_arg' matches 'str'. Also returns the match score in
 * 'outScore' and the matching character positions in 'matches'.

Fixed code:
    if (pat_len > MAX_FUZZY_MATCHES)
	pat_len = MAX_FUZZY_MATCHES;
								col, NULL) > 0)
	    CLEAR_FIELD(matches);
	    int		recursiveScore = 0;
	    int_u	recursiveMatches[MAX_FUZZY_MATCHES];
	    CLEAR_FIELD(recursiveMatches);

	    char_u *next_char = str + (has_mbyte ? (*mb_ptr2len)(str) : 1);
 * Returns TRUE if "pat_arg" matches "str". Also returns the match score in
 * "outScore" and the matching character positions in "matches".
source term_util.vim
" This was using uninitialized memory
func Test_matchfuzzy_initialized()
  CheckRunVimInTerminal

  " This can take a very long time (esp. when using valgrind).  Run in a
  " separate Vim instance and kill it after two seconds.  We only check for
  " memory errors.
  let lines =<< trim END
      lvimgrep [ss [fg*
  END
  call writefile(lines, 'XTest_matchfuzzy', 'D')

  let buf = RunVimInTerminal('-u NONE -X -Z', {})
  call term_sendkeys(buf, ":source XTest_matchfuzzy\n")
  call TermWait(buf, 2000)

  let job = term_getjob(buf)
  if job_status(job) == "run"
    call job_stop(job, "int")
    call TermWait(buf, 50)
  endif

  " clean up
  call StopVimInTerminal(buf)
endfunc

/**/
    1499,
CVE-2023-2609 (C, published 2023-05-09T18:15Z)
Description: value: NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1531.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/vim/vim
Files changed:
src/register.c
src/testdir/test_registers.vim
src/version.c
Commit message: patch 9.0.1531: crash when register contents ends up being invalid

Problem:    Crash when register contents ends up being invalid.
Solution:   Check "y_array" is not NULL.


Vulnerable code:
	if (reg->y_size == 0)

Fixed code:
	if (reg->y_size == 0 || y_current->y_array == NULL)
" This was causing a crash because y_append was ending up being NULL
func Test_zero_y_append()
  " Run in a separate Vim instance because changing 'encoding' may cause
  " trouble for later tests.
  let lines =<< trim END
      d
      silent ?n
      next <sfile>
      so
      sil! norm 0VPSP
      set enc=latin1
       
  END
  call writefile(lines, 'XTest_zero_y_append', 'D')
  call RunVim([], [], '-u NONE -i NONE -e -s -S XTest_zero_y_append -c qa\!')
endfunc

/**/
    1531,
CVE-2023-2610 (C, published 2023-05-09T22:15Z)
Description: value: Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1532.
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/regexp.c
src/testdir/test_substitute.vim
src/version.c
Commit message: patch 9.0.1532: crash when expanding "~" in substitute causes very long text

Problem:    Crash when expanding "~" in substitute causes very long text.
Solution:   Limit the text length to MAXCOL.


Vulnerable code:
    char_u	*tmpsub;
    int		len;
    int		prevlen;
		prevlen = (int)STRLEN(reg_prev_sub);
		tmpsub = alloc(STRLEN(newsub) + prevlen);
		    len = (int)(p - newsub);	// not including ~
		    mch_memmove(tmpsub, newsub, (size_t)len);
		    mch_memmove(tmpsub + len, reg_prev_sub, (size_t)prevlen);
		    STRCPY(tmpsub + len + prevlen, p + 1);
		    if (newsub != source)	// already allocated newsub
		    p = newsub + len + prevlen;

Fixed code:
		// Avoid making the text longer than MAXCOL, it will cause
		// trouble at some point.
		size_t	prevsublen = STRLEN(reg_prev_sub);
		size_t  newsublen = STRLEN(newsub);
		if (prevsublen > MAXCOL || newsublen > MAXCOL
					    || newsublen + prevsublen > MAXCOL)
		{
		    emsg(_(e_resulting_text_too_long));
		    break;
		}

		char_u *tmpsub = alloc(newsublen + prevsublen);
		    size_t prefixlen = p - newsub;	// not including ~
		    mch_memmove(tmpsub, newsub, prefixlen);
		    mch_memmove(tmpsub + prefixlen, reg_prev_sub,
							       prevsublen);
		    STRCPY(tmpsub + prefixlen + prevsublen, p + 1);
		    if (newsub != source)	// allocated newsub before
		    p = newsub + prefixlen + prevsublen;
" Check handling expanding "~" resulting in extremely long text.
func Test_substitute_tilde_too_long()
  enew!

  s/.*/ixxx
  s//~~~~~~~~~AAAAAAA@(

  " Either fails with "out of memory" or "text too long".
  " This can take a long time.
  call assert_fails('sil! norm &&&&&&&&&', ['E1240:\|E342:'])

  bwipe!
endfunc

/**/
    1532,
CVE-2023-46246 (C, published 2023-10-27T19:15Z)
Description: value: Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it's possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.

Severity: nan (CVSS v3 base score: 5.5)
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/cmdhist.c
src/errors.h
src/ex_getln.c
src/testdir/test_history.vim
src/version.c
Commit message: patch 9.0.2068: [security] overflow in :history

Problem:  [security] overflow in :history
Solution: Check that value fits into int

The get_list_range() function, used to parse numbers for the :history
and :clist command internally uses long variables to store the numbers.
However function arguments are integer pointers, which can then
overflow.

Check that the return value from the vim_str2nr() function is not larger
than INT_MAX and if yes, bail out with an error. I guess nobody uses a
cmdline/clist history that needs so many entries... (famous last words).

It is only a moderate vulnerability, so impact should be low.

Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm

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


Vulnerable code:
	semsg(_(e_trailing_characters_str), end);
	    *num2 = (int)num;

Fixed code:
	if (*end != NUL)
	    semsg(_(e_trailing_characters_str), end);
	else
	    semsg(_(e_val_too_large), arg);
EXTERN char e_val_too_large[]
	INIT(= N_("E1510: Value too large: %s"));
	// overflow
	if (num > INT_MAX)
	    return FAIL;

	    // overflow
	    if (num > INT_MAX)
		return FAIL;

	    *num2 = (int)num;
" The following used to overflow and causing an use-after-free
func Test_history_max_val()

  set history=10
  call assert_fails(':history 2147483648', 'E1510:')
  set history&
endfunc

/**/
    2068,
CVE-2023-46246 (C, published 2023-10-27T19:15Z)
Description: value: Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it's possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.

Severity: nan (CVSS v3 base score: 5.5)
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/cmdhist.c
src/errors.h
src/ex_getln.c
src/testdir/test_history.vim
src/version.c
Commit message: patch 9.0.2068: [security] overflow in :history

Problem:  [security] overflow in :history
Solution: Check that value fits into int

The get_list_range() function, used to parse numbers for the :history
and :clist command internally uses long variables to store the numbers.
However function arguments are integer pointers, which can then
overflow.

Check that the return value from the vim_str2nr() function is not larger
than INT_MAX and if yes, bail out with an error. I guess nobody uses a
cmdline/clist history that needs so many entries... (famous last words).

It is only a moderate vulnerability, so impact should be low.

Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm

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


Vulnerable code:
	semsg(_(e_trailing_characters_str), end);
	    *num2 = (int)num;

Fixed code:
	if (*end != NUL)
	    semsg(_(e_trailing_characters_str), end);
	else
	    semsg(_(e_val_too_large), arg);
EXTERN char e_val_too_large[]
	INIT(= N_("E1510: Value too large: %s"));
	// overflow
	if (num > INT_MAX)
	    return FAIL;

	    // overflow
	    if (num > INT_MAX)
		return FAIL;

	    *num2 = (int)num;
" The following used to overflow and causing an use-after-free
func Test_history_max_val()

  set history=10
  call assert_fails(':history 2147483648', 'E1510:')
  set history&
endfunc

/**/
    2068,
CVE-2023-4733 (C, published 2023-09-04T14:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.1840.
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/ex_cmds.c
src/testdir/Make_all.mak
src/testdir/dumps/Test_crash_01.dump
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1840: [security] use-after-free in do_ecmd

Problem:  use-after-free in do_ecmd
Solution: Verify oldwin pointer after reset_VIsual()

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


Vulnerable code:
    /*
     * End Visual mode before switching to another buffer, so the text can be
     * copied into the GUI selection buffer.
     */

Fixed code:
    
     // End Visual mode before switching to another buffer, so the text can be
     // copied into the GUI selection buffer.
     // Careful: may trigger ModeChanged() autocommand
     
    // Should we block autocommands here?
    // autocommands freed window :(
    if (oldwin != NULL && !win_valid(oldwin))
	oldwin = NULL;

	test_crash \
	test_crash.res \
> +0&#ffffff0@74
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
@75
" Some tests, that used to crash Vim
source check.vim
source screendump.vim

CheckScreendump

func Test_crash1()
  " The following used to crash Vim
  let opts = #{wait_for_ruler: 0}
  let args = ' -u NONE -i NONE -n -e -s -S '
  let buf = RunVimInTerminal(args .. ' crash/poc_huaf1', opts)
  call VerifyScreenDump(buf, 'Test_crash_01', {})
  exe buf .. "bw!"

  let buf = RunVimInTerminal(args .. ' crash/poc_huaf2', opts)
  call VerifyScreenDump(buf, 'Test_crash_01', {})
  exe buf .. "bw!"

  let buf = RunVimInTerminal(args .. ' crash/poc_huaf3', opts)
  call VerifyScreenDump(buf, 'Test_crash_01', {})
  exe buf .. "bw!"

endfunc

" vim: shiftwidth=2 sts=2 expandtab
/**/
    1840,