You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In main_loop(), the program called msg_attr((char *)p, keep_msg_attr), and p was equal to keep_msg, and keep_msg_attr was 0, according to the context of the program. And then, msg_attr() called msg_attr_keep(), with p as the argument s and keep_msg_attr as the argument attr. So s was equal to keep_msg and attr was 0 in msg_attr_keep().
Because attr was 0, the program called set_vim_var_string() at message.c:144. And then set_vim_var_string() called vim_strsave(). Finally, In lalloc(), the malloc() at misc.c:924 was called. The call stack is shown below:
#0 0xaeeab1 in lalloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:964
#1 0xaefe36 in alloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:827:12
#2 0xaefe36 in vim_strsave /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1279
#3 0x663cd9 in set_vim_var_string /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/eval.c:7119:24
#4 0x137c631 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:142:2
#5 0x137dacc in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#6 0x136a177 in main_loop /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:1286:3
#7 0x1366b92 in vim_main2 /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:903:5
#8 0x135fa9d in main /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:444:12
#9 0x7ffff6bfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
When the malloc() in this call stack failed, the program would execute the error handling code, and it called do_outofmem_msg() at misc.c:924. And then do_outofmem_msg() called semsg(). Finally, the program called vim_free() with keep_msg as the argument p in msg_start(). The call stack is shown below:
#0 0xaf6391 in vim_free /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1805:2
#1 0x137e522 in f /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:1315:2
#2 0x137c949 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:175:5
#3 0x1383b6d in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#4 0x1383b6d in emsg_core /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:701
#5 0x1384b5a in semsg /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:737:9
#6 0xaeeab1 in do_outofmem_msg /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1024:2
#7 0xaeeab1 in lalloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:964
#8 0xaefe36 in alloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:827:12
#9 0xaefe36 in vim_strsave /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1279
#10 0x663cd9 in set_vim_var_string /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/eval.c:7119:24
#11 0x137c631 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:142:2
#12 0x137dacc in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#13 0x136a177 in main_loop /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:1286:3
#14 0x1366b92 in vim_main2 /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:903:5
#15 0x135fa9d in main /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:444:12
#16 0x7ffff6bfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
As a result, keep_msg was freed, and s in msg_attr_keep() pointed to a space which had been freed. And then, the program came back to msg_attr_keep() (at #11). Finally, the program executed msg_outtrans_attr() at message.c:182 with s as the argument str. In msg_outtrans_attr(), the program called STRLEN(str) while str pointed to a freed address, as a result of which an use-after-free bug was triggered.
To Reproduce
Detailed steps to reproduce the behavior:
Make the malloc() shown at Describe the bug fail.
The program will cause use-after-free bug.
Expected behavior
The program will execute normally when malloc() fails.
Screenshots
The bug was triggered by my own fuzzer and detected by ASAN.
The bug report shown below was reported by ASAN.
AddressSanitizer: heap-use-after-free on address 0x6030004af9b0 at pc 0x000000498cec bp 0x7fffffffb8c0 sp 0x7fffffffb070
READ of size 2 at 0x6030004af9b0 thread T0
#0 0x498ceb in __interceptor_strlen.part.30 (/home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/vim+0x498ceb)
#1 0x137c9a7 in msg_outtrans_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:1438:44
#2 0x137c9a7 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:180
#3 0x137dacc in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#4 0x136a177 in main_loop /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:1286:3
#5 0x1366b92 in vim_main2 /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:903:5
#6 0x135fa9d in main /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:444:12
#7 0x7ffff6bfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#8 0x41c249 in _start (/home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/vim+0x41c249)
0x6030004af9b0 is located 0 bytes inside of 23-byte region [0x6030004af9b0,0x6030004af9c7)
freed by thread T0 here:
#0 0x4dbf30 in __interceptor_free.localalias.0 (/home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/vim+0x4dbf30)
#1 0xaf6391 in vim_free /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1805:2
#2 0x137e522 in msg_start /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:1315:2
#3 0x137c949 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:175:5
#4 0x1383b6d in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#5 0x1383b6d in emsg_core /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:701
#6 0x1384b5a in semsg /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:737:9
#7 0xaeeab1 in do_outofmem_msg /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1024:2
#8 0xaeeab1 in lalloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:964
#9 0xaefe36 in alloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:827:12
#10 0xaefe36 in vim_strsave /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1279
#11 0x663cd9 in set_vim_var_string /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/eval.c:7119:24
#12 0x137c631 in msg_attr_keep /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:142:2
#13 0x137dacc in msg_attr /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:122:12
#14 0x136a177 in main_loop /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:1286:3
#15 0x1366b92 in vim_main2 /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:903:5
#16 0x135fa9d in main /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:444:12
#17 0x7ffff6bfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
previously allocated by thread T0 here:
#0 0x4dc100 in malloc (/home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/vim+0x4dc100)
#1 0xaee895 in lalloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:924:11
#2 0xaefe36 in alloc /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:827:12
#3 0xaefe36 in vim_strsave /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/misc2.c:1279
#4 0x138015f in set_keep_msg /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/message.c:1285:13
#5 0xa85b57 in ml_delete_int /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/memline.c:3632:6
#6 0xa7d743 in ml_delete /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/memline.c:3595:12
#7 0x599448 in del_lines /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/change.c:2418:2
#8 0xc06116 in op_delete /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/ops.c:1977:6
#9 0xb76fbb in do_pending_operator /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/normal.c:1816:9
#10 0xb67f17 in normal_cmd /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/normal.c:1133:5
#11 0x1369488 in main_loop /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:1370:3
#12 0x1366b92 in vim_main2 /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:903:5
#13 0x135fa9d in main /home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/main.c:444:12
#14 0x7ffff6bfab96 in __libc_start_main `/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310`
SUMMARY: AddressSanitizer: heap-use-after-free (/home/fuzz-server/research_project/AFLC++_project/vim_test/vim-2/src/vim+0x498ceb) in __interceptor_strlen.part.30
Environment (please complete the following information):
Vim version: 8.1
OS: Ubuntu 18.04
Terminal: GNOME Terminal
Additional context
This bug was found by my fuzzing tool and the bug is triggered at runtime.
The text was updated successfully, but these errors were encountered:
Describe the bug
In main_loop(), the program called msg_attr((char *)p, keep_msg_attr), and p was equal to keep_msg, and keep_msg_attr was 0, according to the context of the program. And then, msg_attr() called msg_attr_keep(), with p as the argument s and keep_msg_attr as the argument attr. So s was equal to keep_msg and attr was 0 in msg_attr_keep().
Because attr was 0, the program called set_vim_var_string() at message.c:144. And then set_vim_var_string() called vim_strsave(). Finally, In lalloc(), the malloc() at misc.c:924 was called. The call stack is shown below:
When the malloc() in this call stack failed, the program would execute the error handling code, and it called do_outofmem_msg() at misc.c:924. And then do_outofmem_msg() called semsg(). Finally, the program called vim_free() with keep_msg as the argument p in msg_start(). The call stack is shown below:
As a result, keep_msg was freed, and s in msg_attr_keep() pointed to a space which had been freed. And then, the program came back to msg_attr_keep() (at #11). Finally, the program executed msg_outtrans_attr() at message.c:182 with s as the argument str. In msg_outtrans_attr(), the program called STRLEN(str) while str pointed to a freed address, as a result of which an use-after-free bug was triggered.
To Reproduce
Detailed steps to reproduce the behavior:
Expected behavior
The program will execute normally when malloc() fails.
Screenshots
The bug was triggered by my own fuzzer and detected by ASAN.
The bug report shown below was reported by ASAN.
Environment (please complete the following information):
Additional context
This bug was found by my fuzzing tool and the bug is triggered at runtime.
The text was updated successfully, but these errors were encountered: