Dominique Pelle wrote:
> vim-7.4.703 accesses invalid memory when doing:
>
> $ vim -E -u NONE -c 'call search(getline("."))' crash
>
> ... where 'crash' is the attached file (16 bytes).
>
> Asan (address sanitizer) reports:
>
> ==27746== ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x60620001af00 at pc 0x625f1d bp 0x7ffdd32cbb50 sp 0x7ffdd32cbb48
> READ of size 1 at 0x60620001af00 thread T0
> #0 0x625f1c in utf_ptr2char /home/pel/sb/vim/src/mbyte.c:1696
> #1 0x706a2c in find_match_text
> /home/pel/sb/vim/src/regexp_nfa.c:5389 (discriminator 1)
> #2 0x70eda9 in nfa_regexec_both /home/pel/sb/vim/src/regexp_nfa.c:7070
> #3 0x70f8bb in nfa_regexec_multi /home/pel/sb/vim/src/regexp_nfa.c:7298
> #4 0x7101bd in vim_regexec_multi /home/pel/sb/vim/src/regexp.c:8274
> #5 0x741aa4 in searchit /home/pel/sb/vim/src/search.c:639
> #6 0x4956d3 in search_cmn /home/pel/sb/vim/src/eval.c:16365
> #7 0x495f70 in f_search /home/pel/sb/vim/src/eval.c:16515
> #8 0x4799f1 in call_func /home/pel/sb/vim/src/eval.c:8760
> #9 0x478a71 in get_func_tv /home/pel/sb/vim/src/eval.c:8560
> #10 0x4662e1 in ex_call /home/pel/sb/vim/src/eval.c:3505
> #11 0x4f71b0 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940
> #12 0x4edf74 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133
> #13 0x4ecf39 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738
> #14 0x84c849 in exe_commands /home/pel/sb/vim/src/main.c:2922
> #15 0x8469dd in main /home/pel/sb/vim/src/main.c:958
> #16 0x7fc8f5c1bec4 in __libc_start_main
> /build/buildd/eglibc-2.19/csu/libc-start.c:287
> #17 0x405b18 in _start ??:?
> 0x60620001af00 is located 0 bytes to the right of 4096-byte region
> [0x606200019f00,0x60620001af00)
> allocated by thread T0 here:
> #0 0x7fc8f76f841a in malloc ??:?
> #1 0x604823 in lalloc /home/pel/sb/vim/src/misc2.c:926
> #2 0x6045e3 in alloc /home/pel/sb/vim/src/misc2.c:821
> #3 0x8580b9 in mf_alloc_bhdr /home/pel/sb/vim/src/memfile.c:952
> #4 0x8564cf in mf_new /home/pel/sb/vim/src/memfile.c:392 (discriminator 1)
> #5 0x5baa13 in ml_new_data /home/pel/sb/vim/src/memline.c:3545
> #6 0x5abe82 in ml_open /home/pel/sb/vim/src/memline.c:408
> #7 0x405d6e in open_buffer /home/pel/sb/vim/src/buffer.c:98
> #8 0x84bd88 in create_windows /home/pel/sb/vim/src/main.c:2692
> #9 0x8466ac in main /home/pel/sb/vim/src/main.c:881
> #10 0x7fc8f5c1bec4 in __libc_start_main
> /build/buildd/eglibc-2.19/csu/libc-start.c:287
> Shadow bytes around the buggy address:
> 0x0c0cbfffb590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c0cbfffb5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c0cbfffb5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c0cbfffb5c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c0cbfffb5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c0cbfffb5e0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c0cbfffb5f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c0cbfffb600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c0cbfffb610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c0cbfffb620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c0cbfffb630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Heap righ redzone: fb
> Freed Heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack partial redzone: f4
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user: f7
> ASan internal: fe
> ==27746== ABORTING
>
> Bug was found by using a fuzzer:
> 'american fuzzy lop' (http://lcamtuf.coredump.cx/afl/).
>
> Sorry, no patch. Not sure how to fix it.
Well, this turned out to be a tricky one. vim_strchr() happily matches
a character with an illegal byte. Thus the character 255 would match
one byte, and other parts of the code would think it matched two bytes,
which is the actual utf-8 encoding.
After fixing this tests failed. Turns out the equivalence classes were
using negative numbers, resulting in using illegal bytes to match
against, which accidentally worked, because of vim_strchr() matching
illegal bytes.
I'm making a patch that should fix all this.
--
"Beware of bugs in the above code; I have only proved
it correct, not tried it." -- Donald Knuth
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
