hitoshura25/cvefixes huggingface dataset:
CVE-2022-3235 (C, published 2022-09-18T20:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0490.
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_getln.c
src/testdir/test_cmdwin.vim
src/version.c
Commit message: patch 9.0.0490: using freed memory with cmdwin and BufEnter autocmd

Problem:    Using freed memory with cmdwin and BufEnter autocmd.
Solution:   Make sure pointer to b_p_iminsert is still valid.


Vulnerable code:
		cmdline_toggle_langmap(b_im_ptr);
    if (b_im_ptr != NULL && *b_im_ptr != B_IMODE_LMAP)

Fixed code:
    buf_T	*b_im_ptr_buf = NULL;	// buffer where b_im_ptr is valid
	b_im_ptr_buf = curbuf;
		cmdline_toggle_langmap(
				    buf_valid(b_im_ptr_buf) ? b_im_ptr : NULL);
    if (b_im_ptr != NULL && buf_valid(b_im_ptr_buf)
						  && *b_im_ptr != B_IMODE_LMAP)
" This was using a pointer to a freed buffer
func Test_cmdwin_freed_buffer_ptr()
  au BufEnter * next 0| file 
  edit 0
  silent! norm q/

  au! BufEnter
  bwipe!
endfunc

/**/
    490,
CVE-2022-3256 (C, published 2022-09-22T13:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0530.
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/mark.c
src/testdir/test_marks.vim
src/version.c
Commit message: patch 9.0.0530: using freed memory when autocmd changes mark

Problem:    Using freed memory when autocmd changes mark.
Solution:   Copy the mark before editing another buffer.


Vulnerable code:
	    // jump to other file
	    if (buflist_findnr(jmp->fmark.fnum) == NULL)
	    if (buflist_getfile(jmp->fmark.fnum, jmp->fmark.mark.lnum,
							    0, FALSE) == FAIL)
	    curwin->w_cursor = jmp->fmark.mark;

Fixed code:
	    // Make a copy, an autocommand may make "jmp" invalid.
	    fmark_T fmark = jmp->fmark;

	    // jump to the file with the mark
	    if (buflist_findnr(fmark.fnum) == NULL)
	    if (buflist_getfile(fmark.fnum, fmark.mark.lnum, 0, FALSE) == FAIL)
	    curwin->w_cursor = fmark.mark;
" This was using freed memory
func Test_jump_mark_autocmd()
  next 00
  edit 0
  sargument
  au BufEnter 0 all
  sil norm 

  au! BufEnter
  bwipe!
endfunc


/**/
    530,
CVE-2022-3278 (C, published 2022-09-23T22:15Z)
Description: value: NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.0552.
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/eval.c
src/testdir/test_source.vim
src/version.c
Commit message: patch 9.0.0552: crash when using NUL in buffer that uses :source

Problem:    Crash when using NUL in buffer that uses :source.
Solution:   Don't get a next line when skipping over NL.


Vulnerable code:
	    // Shortcut to call a compiled function without overhead.
	    *getnext = TRUE;

Fixed code:
	    // Shortcut to call a compiled function with minimal overhead.
	    *getnext = *p != NL;
func Test_source_buffer_with_NUL_char()
  " This was trying to use a line below the buffer.
  let lines =<< trim END
      if !exists('g:loaded')
        let g:loaded = 1
        source
      endif
  END
  " Can't have a NL in heredoc
  let lines += ["silent! vim9 echo [0 \<NL> ? 'a' : 'b']"]
  call writefile(lines, 'XsourceNul', '')
  edit XsourceNul
  source

  bwipe!
endfunc

/**/
    552,
CVE-2022-3297 (C, published 2022-09-25T19:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0579.
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/move.c
src/testdir/test_ins_complete.vim
src/version.c
Commit message: patch 9.0.0579: using freed memory when 'tagfunc' wipes out buffer

Problem:    Using freed memory when 'tagfunc' wipes out buffer that holds
            'complete'.
Solution:   Make a copy of the option.  Make sure cursor position is valid.


Vulnerable code:
	if (buf == curbuf || wp == NULL)  // first call for this flag/expansion
    char_u	*e_cpt;			// current entry in 'complete'
    pos_T	*cur_match_pos;			// current match position
	    && (st->ins_buf = ins_compl_next_buf(st->ins_buf, *st->e_cpt)) != curbuf)
    static ins_compl_next_state_T st;
	FOR_ALL_BUFFERS(st.ins_buf)
	    st.ins_buf->b_scanned = 0;
	st.e_cpt = (compl_cont_status & CONT_LOCAL)
					    ? (char_u *)"." : curbuf->b_p_cpt;
  call TermWait(buf, 50)
  call TermWait(buf, 100)

Fixed code:
	if (buf == curbuf || !win_valid(wp))
	    // first call for this flag/expansion or window was closed
    char_u	*e_cpt_copy;		// copy of 'complete'
    char_u	*e_cpt;			// current entry in "e_cpt_copy"
    pos_T	*cur_match_pos;		// current match position
	    && (st->ins_buf = ins_compl_next_buf(
					   st->ins_buf, *st->e_cpt)) != curbuf)
    static ins_compl_next_state_T   st;
    static int			    st_cleared = FALSE;
	buf_T *buf;

	FOR_ALL_BUFFERS(buf)
	    buf->b_scanned = 0;
	if (!st_cleared)
	{
	    CLEAR_FIELD(st);
	    st_cleared = TRUE;
	}
	vim_free(st.e_cpt_copy);
	// Make a copy of 'complete', if case the buffer is wiped out.
	st.e_cpt_copy = vim_strsave((compl_cont_status & CONT_LOCAL)
					    ? (char_u *)"." : curbuf->b_p_cpt);
	st.e_cpt = st.e_cpt_copy == NULL ? (char_u *)"" : st.e_cpt_copy;
    buf_T   *orig_curbuf = curbuf;
    if (curbuf != orig_curbuf)
    {
	// In case some completion function switched buffer, don't want to
	// insert the completion elsewhere.
	return -1;
    }

    check_cursor();
  call TermWait(buf, 200)
func s:Tagfunc(t,f,o)
  bwipe!
  return []
endfunc

" This was using freed memory, since 'complete' was in a wiped out buffer.
" Also using a window that was closed.
func Test_tagfunc_wipes_out_buffer()
  new
  set complete=.,t,w,b,u,i
  se tagfunc=s:Tagfunc
  sil norm i

  bwipe!
endfunc


/**/
    579,
CVE-2022-3324 (C, published 2022-09-27T23:15Z)
Description: value: Stack-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0598.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-121 \u2014 Stack-based Buffer Overflow
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Repository: https://github.com/vim/vim
Files changed:
src/testdir/test_cmdwin.vim
src/version.c
src/window.c
Commit message: patch 9.0.0598: using negative array index with negative width window

Problem:    Using negative array index with negative width window.
Solution:   Make sure the window width does not become negative.


Vulnerable code:
    wp->w_width = width;

Fixed code:
" This was resulting in a window with negative width.
" The test doesn't reproduce the illegal memory access though...
func Test_cmdwin_split_often()
  let lines = &lines
  let columns = &columns
  set t_WS=

  try
    set encoding=iso8859
    set ruler
    winsize 0 0
    noremap 0 H
    sil norm 0000000q:
  catch /E36:/
  endtry

  bwipe!
  set encoding=utf8
  let &lines = lines
  let &columns = columns
endfunc

/**/
    598,
		    if (next_curwin_size < 0)
			next_curwin_size = 0;
    // Should we give an error if width < 0?
    wp->w_width = width < 0 ? 0 : width;
CVE-2022-3352 (C, published 2022-09-29T12:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0614.
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/buffer.c
src/spell.c
src/testdir/test_autocmd.vim
src/version.c
Commit message: patch 9.0.0614: SpellFileMissing autocmd may delete buffer

Problem:    SpellFileMissing autocmd may delete buffer.
Solution:   Disallow deleting the current buffer to avoid using freed memory.


Vulnerable code:
	semsg(_(e_attempt_to_delete_buffer_that_is_in_use_str), buf->b_fname);

Fixed code:
    {
	char_u *fname = buf->b_fname != NULL ? buf->b_fname : buf->b_ffname;

	semsg(_(e_attempt_to_delete_buffer_that_is_in_use_str),
				fname != NULL ? fname : (char_u *)"[No Name]");
    }
    // Disallow deleting the current buffer.  Autocommands can do weird things
    // and cause "lang" to be freed.
    ++curbuf->b_locked;


    --curbuf->b_locked;
" this was wiping out the current buffer and using freed memory
func Test_SpellFileMissing_bwipe()
  next 0
  au SpellFileMissing 0 bwipe
  call assert_fails('set spell spelllang=0', 'E937:')

  au! SpellFileMissing
  bwipe
endfunc

/**/
    614,
CVE-2022-3520 (C, published 2022-12-02T19:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0765.
Severity: nan (CVSS v3 base score: 9.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/register.c
src/testdir/test_visual.vim
src/version.c
Commit message: patch 9.0.0765: with a Visual block a put command column may go negative

Problem:    With a Visual block a put command column may go negative.
Solution:   Check that the column does not become negative.


Vulnerable code:

Fixed code:
	if (curbuf->b_op_end.col < 0)
	    curbuf->b_op_end.col = 0;
func Test_visual_block_put_invalid()
  enew!
  behave mswin
  norm yy
  norm v)Ps/^/	
  " this was causing the column to become negative
  silent norm ggv)P

  bwipe!
  behave xterm
endfunc

/**/
    765,
CVE-2022-3591 (C, published 2022-12-02T17:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0789.
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/buffer.c
src/testdir/test_autocmd.vim
src/version.c
Commit message: patch 9.0.0789: dummy buffer ends up in a window

Problem:    Dummy buffer ends up in a window.
Solution:   Disallow navigating to a dummy buffer.


Vulnerable code:

Fixed code:
    if ((action == DOBUF_GOTO || action == DOBUF_SPLIT)
						  && (buf->b_flags & BF_DUMMY))
    {
	// disallow navigating to the dummy buffer
	semsg(_(e_buffer_nr_does_not_exist), count);
	return FAIL;
    }
func Test_autocmd_split_dummy()
  " Autocommand trying to split a window containing a dummy buffer.
  auto BufReadPre * exe "sbuf " .. expand("<abuf>") 
  " Avoid the "W11" prompt
  au FileChangedShell * let v:fcs_choice = 'reload'
  func Xautocmd_changelist()
    cal writefile(['Xtestfile2:4:4'], 'Xerr')
    edit Xerr
    lex 'Xtestfile2:4:4'
  endfunc
  call Xautocmd_changelist()
  call assert_fails('call Xautocmd_changelist()', 'E86:')

  au! BufReadPre
  au! FileChangedShell
  delfunc Xautocmd_changelist
  bwipe! Xerr
  call delete('Xerr')
endfunc

/**/
    789,
CVE-2022-3705 (C, published 2022-10-26T20:15Z)
Description: value: A vulnerability was found in vim and classified as problematic. Affected by this issue is the function qf_update_buffer of the file quickfix.c of the component autocmd Handler. The manipulation leads to use after free. The attack may be launched remotely. Upgrading to version 9.0.0805 is able to address this issue. The name of the patch is d0fab10ed2a86698937e3c3fed2f10bd9bb5e731. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-212324.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/vim/vim
Files changed:
src/quickfix.c
src/testdir/test_quickfix.vim
src/version.c
Commit message: patch 9.0.0805: filetype autocmd may cause freed memory access

Problem:    Filetype autocmd may cause freed memory access.
Solution:   Set the quickfix-busy flag while filling the buffer.


Vulnerable code:

Fixed code:
	// autocommands may cause trouble
	incr_quickfix_busy();


	// always called after incr_quickfix_busy()
	decr_quickfix_busy();
func Test_filetype_autocmd()
  " this changes the location list while it is in use to fill a buffer
  lexpr ''
  lopen
  augroup FT_loclist
    au FileType * call setloclist(0, [], 'f')
  augroup END
  silent! lolder
  lexpr ''

  augroup FT_loclist
    au! FileType
  augroup END
endfunc


/**/
    805,
CVE-2022-4141 (C, published 2022-11-25T14:15Z)
Description: value: Heap based buffer overflow in vim/vim 9.0.0946 and below by allowing an attacker to CTRL-W gf in the expression used in the RHS of the substitute command.
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/proto/normal.pro
src/testdir/test_substitute.vim
src/version.c
src/window.c
Commit message: patch 9.0.0947: invalid memory access in substitute with function

Problem:    Invalid memory access in substitute with function that goes to
            another file.
Solution:   Check for text locked in CTRL-W gf.


Vulnerable code:
	clearopbeep(oap);
    if ((nv_cmds[idx].cmd_flags & NV_NCW)
				&& (check_text_locked(oap) || curbuf_locked()))
    if (check_text_locked(cap->oap))
	return;
    if (curbuf_locked())
    {
	clearop(cap->oap);
    }
 * return FAIL for failure, OK otherwise

Fixed code:
	if (oap != NULL)
	    clearopbeep(oap);
/*
 * If text is locked, "curbuf_lock" or "allbuf_lock" is set:
 * Give an error message, possibly beep and return TRUE.
 * "oap" may be NULL.
 */
    int
check_text_or_curbuf_locked(oparg_T *oap)
{
    if (check_text_locked(oap))
	return TRUE;
    if (curbuf_locked())
    {
	if (oap != NULL)
	    clearop(oap);
	return TRUE;
    }
    return FALSE;
}

    if ((nv_cmds[idx].cmd_flags & NV_NCW) && check_text_or_curbuf_locked(oap))
    if (check_text_or_curbuf_locked(cap->oap))

int check_text_or_curbuf_locked(oparg_T *oap);
" This was editing another file from the expression.
func Test_sub_expr_goto_other_file()
  call writefile([''], 'Xfileone', 'D')
  enew!
  call setline(1, ['a', 'b', 'c', 'd',
	\ 'Xfileone zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz'])

  func g:SplitGotoFile()
    exe "sil! norm 0\<C-W>gf"
    return ''
  endfunc

  $
  s/\%')/\=g:SplitGotoFile()

  delfunc g:SplitGotoFile
  bwipe!
endfunc

/**/
    947,
		if (check_text_or_curbuf_locked(NULL))
		    break;
 * Return FAIL for failure, OK otherwise.
CVE-2022-4292 (C, published 2022-12-05T19:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to 9.0.0882.
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/spell.c
src/testdir/test_spell.vim
src/version.c
Commit message: patch 9.0.0882: using freed memory after SpellFileMissing autocmd uses bwipe

Problem:    Using freed memory after SpellFileMissing autocmd uses bwipe.
Solution:   Bail out if the window no longer exists.


Vulnerable code:
		// destroying the buffer we are using...
		if (!bufref_valid(&bufref))

Fixed code:
		// destroying the buffer we are using or closing the window.
		if (!bufref_valid(&bufref) || !win_valid_any_tab(wp))
func Test_spell_file_missing_bwipe()
  " this was using a window that was wiped out in a SpellFileMissing autocmd
  set spelllang=xy
  au SpellFileMissing * n0
  set spell
  au SpellFileMissing * bw
  snext somefile

  au! SpellFileMissing
  bwipe!
  set nospell spelllang=en
endfunc

/**/
    882,
CVE-2022-4293 (C, published 2022-12-05T19:15Z)
Description: value: Floating Point Comparison with Incorrect Operator in GitHub repository vim/vim prior to 9.0.0804.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-1077 \u2014 Floating Point Comparison with Incorrect Operator
The code performs a comparison such as an
        equality test between two float (floating point) values, but
        it uses comparison operators that do not account for the
        possibility of loss of precision.
Repository: https://github.com/vim/vim
Files changed:
src/eval.c
src/testdir/test_expr.vim
src/version.c
Commit message: patch 9.0.0804: crash when trying to divide a number by -1

Problem:    Crash when trying to divice the largest negative number by -1.
Solution:   Handle this case specifically.


Vulnerable code:
 * Convert list in "arg" into position "psop" and optional file number "fnump".

Fixed code:
    else if (n1 == VARNUM_MIN && n2 == -1)
    {
	// specific case: trying to do VARNUM_MIN / -1 results in a positive
	// number that doesn't fit in varnumber_T and causes an FPE
	result = VARNUM_MAX;
    }
 * Convert list in "arg" into position "posp" and optional file number "fnump".
func Test_divide_by_zero()
  " only tests that this doesn't crash, the result is not important
  echo 0 / 0
  echo 0 / 0 / -1
endfunc

/**/
    804,
CVE-2022-47024 (C, published 2023-01-20T19:15Z)
Description: value: A null pointer dereference issue was discovered in function gui_x11_create_blank_mouse in gui_x11.c in vim 8.1.2269 thru 9.0.0339 allows attackers to cause denial of service or other unspecified impacts.
Severity: nan (CVSS v3 base score: 7.8)
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/gui_x11.c
src/version.c
Commit message: patch 9.0.0339: no check if the return value of XChangeGC() is NULL

Problem:    No check if the return value of XChangeGC() is NULL.
Solution:   Only use the return value when it is not NULL. (closes #11020)


Vulnerable code:
    XDrawPoint(gui.dpy, blank_pixmap, gc, 0, 0);
    XFreeGC(gui.dpy, gc);
	    (XColor*)&gui.norm_pixel, (XColor*)&gui.norm_pixel, 0, 0);

Fixed code:

    if (gc != NULL)
    {
	XDrawPoint(gui.dpy, blank_pixmap, gc, 0, 0);
	XFreeGC(gui.dpy, gc);
    }
		     (XColor*)&gui.norm_pixel, (XColor*)&gui.norm_pixel, 0, 0);
/**/
    339,
CVE-2023-0049 (C, published 2023-01-04T16:15Z)
Description: value: Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.1143.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/vim/vim
Files changed:
src/buffer.c
src/testdir/test_statusline.vim
src/version.c
Commit message: patch 9.0.1143: invalid memory access with bad 'statusline' value

Problem:    Invalid memory access with bad 'statusline' value.
Solution:   Avoid going over the NUL at the end.


Vulnerable code:

Fixed code:
	    if (*s == NUL)  // can happen with "%0"
		break;
func Test_statusline_trailing_percent_zero()
  " this was causing illegal memory access
  set laststatus=2 stl=%!%0
  call assert_fails('redraw', 'E15: Invalid expression: "%0"')
  set laststatus& stl&
endfunc

/**/
    1143,
CVE-2023-0051 (C, published 2023-01-04T18:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1144.
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/message.c
src/proto/strings.pro
src/strings.c
src/testdir/test_cmdline.vim
src/version.c
Commit message: patch 9.0.1144: reading beyond text

Problem:    Reading beyond text.
Solution:   Add strlen_maxlen() and use it.


Vulnerable code:
	if (maxlen > 0 && STRLEN(p) > (size_t)maxlen)
    char_u  *

Fixed code:
	if (maxlen > 0 && vim_strlen_maxlen((char *)p, (size_t)maxlen)
							     >= (size_t)maxlen)
size_t vim_strlen_maxlen(char *s, size_t maxlen);
/*
 * A version of strlen() that has a maximum length.
 */
    size_t
vim_strlen_maxlen(char *s, size_t maxlen)
{
    size_t i;
    for (i = 0; i < maxlen; ++i)
	if (s[i] == NUL)
	    break;
    return i;
}

    char_u *
func Test_multibyte_expression()
  " This was using uninitialized memory.
  let lines =<< trim END
      set verbose=6
      norm @=ٷ
      qall!
  END
  call writefile(lines, 'XmultiScript', 'D')
  call RunVim('', '', '-u NONE -n -e -s -S XmultiScript')
endfunc

/**/
    1144,
CVE-2023-0054 (C, published 2023-01-04T19:15Z)
Description: value: Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1145.
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/eval.c
src/testdir/test_substitute.vim
src/version.c
Commit message: patch 9.0.1145: invalid memory access with recursive substitute expression

Problem:    Invalid memory access with recursive substitute expression.
Solution:   Check the return value of vim_regsub().


Vulnerable code:

Fixed code:
	    if (sublen <= 0)
	    {
		ga_clear(&ga);
		break;
	    }
func Test_recursive_expr_substitute()
  " this was reading invalid memory
  let lines =<< trim END
      func Repl(g, n)
        s
        r%:s000
      endfunc
      next 0
      let caught = 0
      s/\%')/\=Repl(0, 0)
      qall!
  END
  call writefile(lines, 'XexprSubst', 'D')
  call RunVim([], [], '--clean -S XexprSubst')
endfunc

/**/
    1145,