Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@dpelle
Copy link
Member

@dpelle dpelle commented Mar 1, 2017

afl-fuzz found another case that causes invalid memory access
in vim-8.0.397 and older. The bug is detected by asan, but not by
valgrind somehow.

Steps to reproduced:

$ cat > bug.vim <<EOF
norm=eccdo
norm=et鏏
EOF

$ vim -u NONE -N -e -s -S searchc-bug.vim  -c 'qa!'
=================================================================
==8420==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000016673 at pc 0x00000049bceb bp 0x7ffd2cd38460 sp 0x7ffd2cd37c10
READ of size 3 at 0x602000016673 thread T0
    #0 0x49bcea in __interceptor_memcmp ??:?
    #1 0xa751d3 in searchc /home/pel/sb/vim/src/search.c:1698
    #2 0x8b88b6 in nv_csearch /home/pel/sb/vim/src/normal.c:6420 (discriminator 1)
    #3 0x890d3a in normal_cmd /home/pel/sb/vim/src/normal.c:1150
    #4 0x6b9231 in exec_normal /home/pel/sb/vim/src/ex_docmd.c:10419
    #5 0x6b8fd4 in exec_normal_cmd /home/pel/sb/vim/src/ex_docmd.c:10402
    #6 0x6b8a90 in ex_normal /home/pel/sb/vim/src/ex_docmd.c:10311
    #7 0x69e694 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2981
    #8 0x68d704 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1120
    #9 0x6854bd in do_source /home/pel/sb/vim/src/ex_cmds2.c:4306
    #10 0x68359e in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:3919
    #11 0x683620 in ex_source /home/pel/sb/vim/src/ex_cmds2.c:3894
    #12 0x69e694 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2981
    #13 0x68d704 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1120
    #14 0x690e35 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:720
    #15 0xc6c83d in exe_commands /home/pel/sb/vim/src/main.c:2905
    #16 0xc6934b in vim_main2 /home/pel/sb/vim/src/main.c:781
    #17 0xc62130 in main /home/pel/sb/vim/src/main.c:415
    #18 0x7f90fe275f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
    #19 0x41e5cb in _start ??:?

0x602000016673 is located 0 bytes to the right of 3-byte region [0x602000016670,0x602000016673)
allocated by thread T0 here:
    #0 0x4e1f76 in malloc ??:?
    #1 0x846928 in lalloc /home/pel/sb/vim/src/misc2.c:942
    #2 0x846c87 in alloc_check /home/pel/sb/vim/src/misc2.c:885
    #3 0x80d276 in ins_str /home/pel/sb/vim/src/misc1.c:2395
    #4 0x594ae4 in insertchar /home/pel/sb/vim/src/edit.c:6206
    #5 0x5884ba in insert_special /home/pel/sb/vim/src/edit.c:5966
    #6 0x56af9e in edit /home/pel/sb/vim/src/edit.c:1539
    #7 0x8fd62c in op_change /home/pel/sb/vim/src/ops.c:2765
    #8 0x89b360 in do_pending_operator /home/pel/sb/vim/src/normal.c:1925
    #9 0x890f83 in normal_cmd /home/pel/sb/vim/src/normal.c:1183
    #10 0x6b9231 in exec_normal /home/pel/sb/vim/src/ex_docmd.c:10419
    #11 0x6b8fd4 in exec_normal_cmd /home/pel/sb/vim/src/ex_docmd.c:10402
    #12 0x6b8a90 in ex_normal /home/pel/sb/vim/src/ex_docmd.c:10311
    #13 0x69e694 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2981
    #14 0x68d704 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1120
    #15 0x6854bd in do_source /home/pel/sb/vim/src/ex_cmds2.c:4306
    #16 0x68359e in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:3919
    #17 0x683620 in ex_source /home/pel/sb/vim/src/ex_cmds2.c:3894
    #18 0x69e694 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2981
    #19 0x68d704 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1120
    #20 0x690e35 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:720
    #21 0xc6c83d in exe_commands /home/pel/sb/vim/src/main.c:2905
    #22 0xc6934b in vim_main2 /home/pel/sb/vim/src/main.c:781
    #23 0xc62130 in main /home/pel/sb/vim/src/main.c:415
    #24 0x7f90fe275f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/pel/sb/vim/src/vim+0x49bcea)
Shadow bytes around the buggy address:
  0x0c047fffac70: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
  0x0c047fffac80: fa fa fd fd fa fa fd fd fa fa 00 00 fa fa 00 00
  0x0c047fffac90: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x0c047fffaca0: fa fa 00 00 fa fa 04 fa fa fa fd fd fa fa fd fa
  0x0c047fffacb0: fa fa fd fa fa fa fd fa fa fa 01 fa fa fa 00 fa
=>0x0c047fffacc0: fa fa 01 fa fa fa 02 fa fa fa fd fa fa fa[03]fa
  0x0c047fffacd0: fa fa 06 fa fa fa 01 fa fa fa 01 fa fa fa 01 fa
  0x0c047ffface0: fa fa 02 fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffacf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffad00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffad10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==8420==ABORTING
ASAN:DEADLYSIGNAL
=================================================================

The crash happen at search.c:1698:

1698     if (memcmp(p + col, lastc_bytes, lastc_bytelen) == 0

Adding printf(), I see that:

p=0x602000016670 pointing to string "do",  col=1 lastc_bytes="鏏" lastc_bytelen=3

Bug happen because memcpy at search:1689 compares 3 bytes which can
go beyond end of string p+col. Using STRNCMP() instead of memcmp() fixes it.

I also added a test that triggers the invalid memory access prior to the fix.

@dpelle
Copy link
Member Author

dpelle commented Mar 1, 2017

I can reproduce the crash with a simpler case:

norm ixx
norm 0t鏏

I'll update the test to use these simpler commands.

@brammool brammool closed this in 66727e1 Mar 1, 2017
chrisbra pushed a commit to chrisbra/vim that referenced this pull request Mar 25, 2017
Problem:    Illegal memory access with "t".
Solution:   Use strncmp() instead of memcmp(). (Dominique Pelle, closes vim#1528)
desvp pushed a commit to desvp/vim that referenced this pull request May 30, 2017
Problem:    Illegal memory access with "t".
Solution:   Use strncmp() instead of memcmp(). (Dominique Pelle, closes vim#1528)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant