fix segmentation fault in tabline format parser#9800
Closed
brandon1024 wants to merge 1 commit into
Closed
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9800 +/- ##
==========================================
- Coverage 81.76% 81.59% -0.17%
==========================================
Files 167 167
Lines 186400 186400
Branches 42020 42020
==========================================
- Hits 152403 152089 -314
- Misses 21599 21885 +286
- Partials 12398 12426 +28
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Contributor
Author
|
Here is the output from Valgrind, before the fix: Details==19611== Memcheck, a memory error detector ==19611== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19611== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==19611== Command: /home/brandon/dev/other/vim/src/vim --clean ==19611== Parent PID: 18457 ==19611== ==19611== Invalid write of size 8 ==19611== at 0x15C2A3: build_stl_str_hl (buffer.c:5034) ==19611== by 0x2F4BA3: win_redr_custom (screen.c:1322) ==19611== by 0x2FAA36: draw_tabline (screen.c:4436) ==19611== by 0x18E8EB: update_screen (drawscreen.c:259) ==19611== by 0x41A9FE: main_loop (main.c:1401) ==19611== by 0x419F3D: vim_main2 (main.c:877) ==19611== by 0x41963B: main (main.c:424) ==19611== Address 0x6f1aa00 is 0 bytes after a block of size 320 alloc'd ==19611== at 0x483877F: malloc (vg_replace_malloc.c:307) ==19611== by 0x149EC0: lalloc (alloc.c:248) ==19611== by 0x149D73: alloc (alloc.c:151) ==19611== by 0x15956F: build_stl_str_hl (buffer.c:4173) ==19611== by 0x2F4BA3: win_redr_custom (screen.c:1322) ==19611== by 0x2FAA36: draw_tabline (screen.c:4436) ==19611== by 0x18E8EB: update_screen (drawscreen.c:259) ==19611== by 0x41A9FE: main_loop (main.c:1401) ==19611== by 0x419F3D: vim_main2 (main.c:877) ==19611== by 0x41963B: main (main.c:424) ==19611== ==19611== Invalid write of size 4 ==19611== at 0x15C2B1: build_stl_str_hl (buffer.c:5035) ==19611== by 0x2F4BA3: win_redr_custom (screen.c:1322) ==19611== by 0x2FAA36: draw_tabline (screen.c:4436) ==19611== by 0x18E8EB: update_screen (drawscreen.c:259) ==19611== by 0x41A9FE: main_loop (main.c:1401) ==19611== by 0x419F3D: vim_main2 (main.c:877) ==19611== by 0x41963B: main (main.c:424) ==19611== Address 0x6f1aa08 is 8 bytes after a block of size 320 alloc'd ==19611== at 0x483877F: malloc (vg_replace_malloc.c:307) ==19611== by 0x149EC0: lalloc (alloc.c:248) ==19611== by 0x149D73: alloc (alloc.c:151) ==19611== by 0x15956F: build_stl_str_hl (buffer.c:4173) ==19611== by 0x2F4BA3: win_redr_custom (screen.c:1322) ==19611== by 0x2FAA36: draw_tabline (screen.c:4436) ==19611== by 0x18E8EB: update_screen (drawscreen.c:259) ==19611== by 0x41A9FE: main_loop (main.c:1401) ==19611== by 0x419F3D: vim_main2 (main.c:877) ==19611== by 0x41963B: main (main.c:424) ... With these changes applied, these invalid writes are no longer present in the Valgrind output. |
When parsing the statusline/tabline format string, highlight information is stored in an array which has size 20 by default. The last item in this array is used to indicate the end of the array, with struct members being set to NULL/0. When there are exactly 20 highlight items in the format string, the array is not resized to account for the last item used to indicate the end of the array. When copying the items to an array to be passed back to the caller, the routine attempts to write beyond the size of the array, often resulting in a segmentation fault. To address this, update parser to allocate one more entry in the array to account for the array end indicator. A test was introduced that validates the fix when tests are run with valgrind memcheck.
seandewar
added a commit
to seandewar/neovim
that referenced
this pull request
Feb 19, 2022
Problem: Illegal memory access when using exactly 20 highlights.
Solution: Add one more item in the array. (Brandon Richardson,
closes vim/vim#9800)
vim/vim@a493b65
seandewar
added a commit
to seandewar/neovim
that referenced
this pull request
Feb 19, 2022
Problem: Illegal memory access when using exactly 20 highlights.
Solution: Add one more item in the array. (Brandon Richardson,
closes vim/vim#9800)
vim/vim@a493b65
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
When parsing the statusline/tabline format string, highlight information
is stored in an array which has size 20 by default. The last item in
this array is used to indicate the end of the array, with struct members
being set to NULL/0.
When there are exactly 20 highlight items in the format string, the
array is not resized to account for the last item used to indicate the
end of the array. When copying the items to an array to be passed back
to the caller, the routine attempts to write beyond the size of the
array, often resulting in a segmentation fault.
To address this, update parser to allocate one more entry in the array
to account for the array end indicator. A test was introduced that
validates the fix when tests are run with valgrind memcheck.