Fixed invalid memory access with range command #1455
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Dominique Pellé wrote:
This PR fixes an invalid memory access bug found by afl-fuzz.
Steps to reproduce:
$ cat > inv-mem.vim <<EOF
c
x
x
..
There should be a single dot in above line, not 2
to end the :change command.
I wrote it correctly in the github pull request.
Why is the email notification messing up the
message and putting 2 dots instead of 2!?
Dominique
|
|
Hi Dominique!
On Mi, 08 Feb 2017, Dominique Pellé wrote:
Dominique Pellé wrote:
> This PR fixes an invalid memory access bug found by afl-fuzz.
>
> Steps to reproduce:
>
> $ cat > inv-mem.vim <<EOF
> c
> x
> x
> ..
There should be a single dot in above line, not 2
to end the :change command.
I wrote it correctly in the github pull request.
Why is the email notification messing up the
message and putting 2 dots instead of 2!?
Because a single dot is ending a message in SMTP. Therefore the script
does some dot stuffing by adding another dot. However, it looks like
that this does not work correctly. I don't have an easy way to fix this.
Best,
Christian
--
Noch ist es Tag; da rühre sich der Mann! Die Nacht tritt ein, da
niemand wirken kann.
-- Johann Wolfgang von Goethe
|
|
Dominique wrote:
This PR fixes an invalid memory access bug found by afl-fuzz.
Steps to reproduce:
```
$ cat > inv-mem.vim <<EOF
c
x
x
.
1;y
EOF
$ valgrind vim -u NONE -S inv-mem.vim 2> valgrind.log
```
Then quit vim with :q! and valgrind.log contains errors:
```
==5012== Memcheck, a memory error detector
==5012== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5012== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==5012== Command: vim -u NONE -S inv-mem.vim
==5012==
==5012== Invalid read of size 1
==5012== at 0x538914: utf_head_off (mbyte.c:3746)
==5012== by 0x66E1E7: getvcol (charset.c:1307)
==5012== by 0x66E7FA: getvvcol (charset.c:1481)
==5012== by 0x53398C: curs_columns (move.c:964)
==5012== by 0x533434: validate_cursor (move.c:644)
==5012== by 0x675EFB: main_loop (main.c:1210)
==5012== by 0x674783: vim_main2 (main.c:877)
==5012== by 0x6722A3: main (main.c:415)
==5012== Address 0x7e6ad80 is 0 bytes after a block of size 4,096 alloc'd
==5012== at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
==5012== by 0x52A28A: lalloc (misc2.c:942)
==5012== by 0x52A227: alloc (misc2.c:840)
==5012== by 0x678F0D: mf_alloc_bhdr (memfile.c:907)
==5012== by 0x678B7B: mf_new (memfile.c:381)
==5012== by 0x506AE0: ml_new_data (memline.c:3513)
==5012== by 0x506564: ml_open (memline.c:400)
==5012== by 0x42BB5F: open_buffer (buffer.c:163)
==5012== by 0x675086: create_windows (main.c:2677)
==5012== by 0x6743B1: vim_main2 (main.c:704)
==5012== by 0x6722A3: main (main.c:415)
(etc.)
```
Doing a bissection, I found that bug started with vim-8.0.0133:
```
commit fe38b49
Author: Bram Moolenaar ***@***.***>
Date: Sun Dec 11 21:34:23 2016 +0100
patch 8.0.0133
Problem: "2;'(" causes ml_get errors in an empty buffer. (Dominique Pelle)
Solution: Check the cursor line earlier.
```
I was not able to completely automate reproduction of the bug somehow.
So I have no test.
Thanks for fixing this. I managed to have a test reproduce the problem
with your commands and then a :diffsplit. That triggers
validate_cursor(). Going back to the main loop is not possible in a
new style test.
…--
Computers make very fast, very accurate, mistakes.
/// 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 ///
|
chrisbra
pushed a commit
to chrisbra/vim
that referenced
this pull request
Mar 25, 2017
Problem: Illegal memory access with "1;y".
Solution: Call check_cursor() instead of check_cursor_lnum(). (Dominique
Pelle, closes vim#1455)
desvp
pushed a commit
to desvp/vim
that referenced
this pull request
May 30, 2017
Problem: Illegal memory access with "1;y".
Solution: Call check_cursor() instead of check_cursor_lnum(). (Dominique
Pelle, closes vim#1455)
justinmk
pushed a commit
to neovim/neovim
that referenced
this pull request
Sep 17, 2017
Problem: Illegal memory access with "1;y".
Solution: Call check_cursor() instead of check_cursor_lnum(). (Dominique
Pelle, closes vim/vim#1455)
vim/vim@f1f6f3f
nateozem
pushed a commit
to nateozem/neovim
that referenced
this pull request
Oct 5, 2017
Problem: Illegal memory access with "1;y".
Solution: Call check_cursor() instead of check_cursor_lnum(). (Dominique
Pelle, closes vim/vim#1455)
vim/vim@f1f6f3f
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes an invalid memory access bug found by afl-fuzz.
Steps to reproduce:
Then quit vim with :q! and valgrind.log contains errors:
Doing a bissection, I found that bug started with vim-8.0.0133:
I was not able to completely automate reproduction of the bug somehow.
So I have no test.