heap-use-after-free in ex_cbuffer #2470
Comments
|
Hi,
On Mon, Dec 18, 2017 at 4:19 PM, gy741 ***@***.***> wrote:
Hello.
I found a heap-use-after-free bug in vim.
Please confirm.
Thanks.
Summary: heap-use-after-free
OS: CentOS 7 64bit
Version: b254af3
PoC Download: free_ex_cbuffer.zip
When I uncompress this file, the resulting file contains some undecipherable
data. Can you attach a sample Vim script to reproduce this problem?
Thanks,
Yegappan
…
Steps to reproduce:
1.Download the .POC files.
2.Compile the source code with ASan.
3.Execute the following command
: ./vim -u NONE -Z -X -e -s -S $POC -c :qa!
=================================================================
==22864==ERROR: AddressSanitizer: heap-use-after-free on address
0x61a00001b088 at pc 0x000000ee0956 bp 0x7ffe1d926970 sp 0x7ffe1d926968
READ of size 4 at 0x61a00001b088 thread T0
#0 0xee0955 in ex_cbuffer /home/karas/vim/src/quickfix.c:5569:32
#1 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#2 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#3 0x813fb7 in do_source /home/karas/vim/src/ex_cmds2.c:4411:5
#4 0x810477 in cmd_source /home/karas/vim/src/ex_cmds2.c:4024:14
#5 0x810596 in ex_source /home/karas/vim/src/ex_cmds2.c:3999:2
#6 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#7 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#8 0x82c835 in do_cmdline_cmd /home/karas/vim/src/ex_docmd.c:671:12
#9 0x1658084 in exe_commands /home/karas/vim/src/main.c:2953:2
#10 0x1651bc6 in vim_main2 /home/karas/vim/src/main.c:800:2
#11 0x1642d2d in main /home/karas/vim/src/main.c:429:12
#12 0x7f24abc4282f in __libc_start_main
/build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
#13 0x41aaa8 in _start (/home/karas/vim/src/vim+0x41aaa8)
0x61a00001b088 is located 8 bytes inside of 1216-byte region
[0x61a00001b080,0x61a00001b540)
freed by thread T0 here:
#0 0x4baa50 in __interceptor_cfree.localalias.0
(/home/karas/vim/src/vim+0x4baa50)
#1 0xbf0b8b in vim_free /home/karas/vim/src/misc2.c:1801:2
#2 0xe96e04 in ll_free_all /home/karas/vim/src/quickfix.c:1419:2
#3 0xe967ba in qf_free_all /home/karas/vim/src/quickfix.c:1432:2
#4 0x148f76a in win_free /home/karas/vim/src/window.c:4692:5
#5 0x14abdf4 in win_free_mem /home/karas/vim/src/window.c:2572:5
#6 0x1475d99 in win_close /home/karas/vim/src/window.c:2413:10
#7 0x5062cf in do_buffer /home/karas/vim/src/buffer.c:1456:10
#8 0x50d85f in do_bufdel /home/karas/vim/src/buffer.c:1133:8
#9 0x89ad33 in ex_bunload /home/karas/vim/src/ex_docmd.c:5535:19
#10 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#11 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#12 0x9bc1d0 in apply_autocmds_group /home/karas/vim/src/fileio.c:9719:2
#13 0x983745 in apply_autocmds /home/karas/vim/src/fileio.c:9253:12
#14 0xedf37b in ex_cbuffer /home/karas/vim/src/quickfix.c:5530:28
#15 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#16 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#17 0x813fb7 in do_source /home/karas/vim/src/ex_cmds2.c:4411:5
#18 0x810477 in cmd_source /home/karas/vim/src/ex_cmds2.c:4024:14
#19 0x810596 in ex_source /home/karas/vim/src/ex_cmds2.c:3999:2
#20 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#21 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#22 0x82c835 in do_cmdline_cmd /home/karas/vim/src/ex_docmd.c:671:12
#23 0x1658084 in exe_commands /home/karas/vim/src/main.c:2953:2
#24 0x1651bc6 in vim_main2 /home/karas/vim/src/main.c:800:2
#25 0x1642d2d in main /home/karas/vim/src/main.c:429:12
#26 0x7f24abc4282f in __libc_start_main
/build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
previously allocated by thread T0 here:
#0 0x4babd8 in malloc (/home/karas/vim/src/vim+0x4babd8)
#1 0xbece08 in lalloc /home/karas/vim/src/misc2.c:954:21
#2 0xbecd57 in alloc /home/karas/vim/src/misc2.c:852:13
#3 0xe9b711 in ll_new_list /home/karas/vim/src/quickfix.c:1536:23
#4 0xe9200f in ll_get_or_alloc_list
/home/karas/vim/src/quickfix.c:1564:16
#5 0xedefb6 in ex_cbuffer /home/karas/vim/src/quickfix.c:5514:7
#6 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#7 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#8 0x813fb7 in do_source /home/karas/vim/src/ex_cmds2.c:4411:5
#9 0x810477 in cmd_source /home/karas/vim/src/ex_cmds2.c:4024:14
#10 0x810596 in ex_source /home/karas/vim/src/ex_cmds2.c:3999:2
#11 0x847da1 in do_one_cmd /home/karas/vim/src/ex_docmd.c:2908:2
#12 0x82727d in do_cmdline /home/karas/vim/src/ex_docmd.c:1071:17
#13 0x82c835 in do_cmdline_cmd /home/karas/vim/src/ex_docmd.c:671:12
#14 0x1658084 in exe_commands /home/karas/vim/src/main.c:2953:2
#15 0x1651bc6 in vim_main2 /home/karas/vim/src/main.c:800:2
#16 0x1642d2d in main /home/karas/vim/src/main.c:429:12
#17 0x7f24abc4282f in __libc_start_main
/build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
SUMMARY: AddressSanitizer: heap-use-after-free
/home/karas/vim/src/quickfix.c:5569:32 in ex_cbuffer
Shadow bytes around the buggy address:
0x0c347fffb5c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c347fffb5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c347fffb5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c347fffb5f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c347fffb600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c347fffb610: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c347fffb620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c347fffb630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c347fffb640: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c347fffb650: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c347fffb660: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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 right 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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==22864==ABORTING
=================
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001,
Innovation hub for high Performance Computing]
|
|
Although it can be useful to find bugs by throwing a garbage script at Vim, we do need to be able to get a reasonable script to reproduce it. It's hard enough to track down leaks with valid code. Unless someone sees what is happening and ideally be able to reproduce it, I would close this issue. |
|
@qy741 wrote:
I'll find time to minimize it later today, and hopefully come |
|
I can reproduce it with vim-8.0.1406 with this simpler case: It's again a case of using a rogue autocommand that |
|
Hi Dominique,
On Tue, Dec 19, 2017 at 12:31 AM, Dominique Pellé ***@***.***> wrote:
I can reproduce it with vim-8.0.1406 with this simpler case:
$ ./vim -u NONE -c'sv x' -c'au * * bw' -clb -cq
Vim: Caught deadly signal SEGV
Thanks for the simplified test. I am attaching a patch for this
crash with a test.
Regards,
Yegappan
Vim: Finished.
Segmentation fault (core dumped)
$ valgrind --num-callers=50 ./vim -u NONE -e -s -c'sv x' -c'au * * bw' -clb
-cq
==7897== Memcheck, a memory error detector
==7897== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7897== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright
info
==7897== Command: ./vim -u NONE -e -s -csv\ x -cau\ *\ *\ bw -clb -cq
==7897==
==7897== Invalid read of size 4
==7897== at 0x5221D3: ex_cbuffer (quickfix.c:5569)
==7897== by 0x468ABC: do_one_cmd (ex_docmd.c:2908)
==7897== by 0x464D3D: do_cmdline (ex_docmd.c:1071)
==7897== by 0x625A4C: exe_commands (main.c:2953)
==7897== by 0x625A4C: vim_main2 (main.c:800)
==7897== by 0x6245E4: main (main.c:429)
==7897== Address 0xce430f8 is 8 bytes inside a block of size 1,216 free'd
==7897== at 0x4C2ECF0: free (vg_replace_malloc.c:530)
==7897== by 0x51B9D7: qf_free_all (quickfix.c:1432)
==7897== by 0x5D60A0: win_free (window.c:4692)
==7897== by 0x5D3C83: win_free_mem (window.c:2572)
==7897== by 0x5D3C83: win_close (window.c:2413)
==7897== by 0x410BD2: do_buffer (buffer.c:1456)
==7897== by 0x411B9A: do_bufdel (buffer.c:1133)
==7897== by 0x46F1D3: ex_bunload (ex_docmd.c:5535)
==7897== by 0x468ABC: do_one_cmd (ex_docmd.c:2908)
==7897== by 0x464D3D: do_cmdline (ex_docmd.c:1071)
==7897== by 0x492EA7: apply_autocmds_group (fileio.c:9719)
==7897== by 0x48B519: apply_autocmds (fileio.c:9253)
==7897== by 0x5220B7: ex_cbuffer (quickfix.c:5530)
==7897== by 0x468ABC: do_one_cmd (ex_docmd.c:2908)
==7897== by 0x464D3D: do_cmdline (ex_docmd.c:1071)
==7897== by 0x625A4C: exe_commands (main.c:2953)
==7897== by 0x625A4C: vim_main2 (main.c:800)
==7897== by 0x6245E4: main (main.c:429)
==7897== Block was alloc'd at
==7897== at 0x4C2DBF6: malloc (vg_replace_malloc.c:299)
==7897== by 0x4D4E87: lalloc (misc2.c:954)
==7897== by 0x522009: ll_new_list (quickfix.c:1536)
==7897== by 0x522009: ll_get_or_alloc_list (quickfix.c:1564)
==7897== by 0x522009: ex_cbuffer (quickfix.c:5514)
==7897== by 0x468ABC: do_one_cmd (ex_docmd.c:2908)
==7897== by 0x464D3D: do_cmdline (ex_docmd.c:1071)
==7897== by 0x625A4C: exe_commands (main.c:2953)
==7897== by 0x625A4C: vim_main2 (main.c:800)
==7897== by 0x6245E4: main (main.c:429)
(more errors after that)
It's again a case of using a rogue autocommand that
wipes out the buffer.
diff --git a/src/quickfix.c b/src/quickfix.c
index 6e80ddfca..1a9da025c 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -5520,14 +5520,6 @@ ex_cbuffer(exarg_T *eap)
#endif
int res;
- if (eap->cmdidx == CMD_lbuffer || eap->cmdidx == CMD_lgetbuffer
- || eap->cmdidx == CMD_laddbuffer)
- {
- qi = ll_get_or_alloc_list(curwin);
- if (qi == NULL)
- return;
- }
-
#ifdef FEAT_AUTOCMD
switch (eap->cmdidx)
{
@@ -5549,6 +5541,15 @@ ex_cbuffer(exarg_T *eap)
}
#endif
+ if (eap->cmdidx == CMD_lbuffer
+ || eap->cmdidx == CMD_lgetbuffer
+ || eap->cmdidx == CMD_laddbuffer)
+ {
+ qi = ll_get_or_alloc_list(curwin);
+ if (qi == NULL)
+ return;
+ }
+
if (*eap->arg == NUL)
buf = curbuf;
else if (*skipwhite(skipdigits(eap->arg)) == NUL)
diff --git a/src/testdir/test_quickfix.vim b/src/testdir/test_quickfix.vim
index 8d0c198ba..c5e902130 100644
--- a/src/testdir/test_quickfix.vim
+++ b/src/testdir/test_quickfix.vim
@@ -3031,3 +3031,10 @@ func Test_ll_window_ctx()
enew | only
endfunc
+" The following test used to crash vim
+func Test_lbuffer_crash()
+ sp Xtest
+ au QuickFixCmdPre * bw
+ lbuffer
+ au! QuickFixCmdPre
+endfunc
|
|
Hi Bram,
On Mon, Dec 18, 2017 at 11:42 PM, Bram Moolenaar ***@***.***> wrote:
Although it can be useful to find bugs by throwing a garbage script at Vim,
we do need to be able to get a reasonable script to reproduce it. It's hard
enough to track down leaks with valid code. Unless someone sees what is
happening and ideally be able to reproduce it, I would close this issue.
I have the fixes for all the reported crashes. All of them are caused by an
autocmd removing the window/buffer which is still being used by the
quickfix code. I am trying to come up with simple test cases to reproduce
the crashes.
Regards,
Yegappan
|
|
Yegappan wrote:
On Mon, Dec 18, 2017 at 11:42 PM, Bram Moolenaar
***@***.***> wrote:
> Although it can be useful to find bugs by throwing a garbage script at Vim,
> we do need to be able to get a reasonable script to reproduce it. It's hard
> enough to track down leaks with valid code. Unless someone sees what is
> happening and ideally be able to reproduce it, I would close this issue.
>
I have the fixes for all the reported crashes. All of them are caused by an
autocmd removing the window/buffer which is still being used by the
quickfix code. I am trying to come up with simple test cases to reproduce
the crashes.
Very good. I'll hold off from the other reported problems related to
quickfix then.
…--
In a world without fences, who needs Gates and Windows?
/// Bram Moolenaar -- Bram@Moolenaar.net -- 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 ///
|
|
Yegappan wrote:
On Tue, Dec 19, 2017 at 12:31 AM, Dominique Pell=C3=A9
***@***.***> wrote:
> I can reproduce it with vim-8.0.1406 with this simpler case:
>
> $ ./vim -u NONE -c'sv x' -c'au * * bw' -clb -cq
> Vim: Caught deadly signal SEGV
>
Thanks for the simplified test. I am attaching a patch for this
crash with a test.
Thanks. I had just made a fix for this, it's very similar.
…--
Don't drink and drive. You might hit a bump and spill your beer.
/// Bram Moolenaar -- Bram@Moolenaar.net -- 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 ///
|
adizero
pushed a commit
to adizero/vim
that referenced
this issue
May 19, 2018
Problem: Accessing freed memory in :cbuffer. Solution: Get quickfix list after executing autocmds. (closes vim#2470)
janlazo
added a commit
to janlazo/neovim
that referenced
this issue
Aug 15, 2018
Problem: Accessing freed memory in :cbuffer. Solution: Get quickfix list after executing autocmds. (closes vim/vim#2470) vim/vim@aaf6e43
janlazo
added a commit
to janlazo/neovim
that referenced
this issue
Aug 15, 2018
Problem: Accessing freed memory in :cbuffer. Solution: Get quickfix list after executing autocmds. (closes vim/vim#2470) vim/vim@aaf6e43
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello.
I found a heap-use-after-free bug in vim.
Please confirm.
Thanks.
Summary: heap-use-after-free
OS: CentOS 7 64bit
Version: b254af3
PoC Download: free_ex_cbuffer.zip
Steps to reproduce:
1.Download the .POC files.
2.Compile the source code with ASan.
3.Execute the following command
: ./vim -u NONE -Z -X -e -s -S $POC -c :qa!
=================
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001, Innovation hub for high Performance Computing]
The text was updated successfully, but these errors were encountered: