Re: [LFS Trac] #5956: vim-9.2.0671 (Security Update) (was: vim-9.2.0663 (Security Update))

#5956: vim-9.2.0671 (Security Update)
-------------------------+-----------------------
 Reporter:  Joe Locash   |       Owner:  lfs-book
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  13.1
Component:  Book         |     Version:  git
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-----------------------
Changes (by Joe Locash):

 * summary:  vim-9.2.0663 (Security Update) => vim-9.2.0671 (Security
              Update)

Comment:

 A couple more...

 {{{
 Out-of-bounds Read in Text Property Count in Vim < 9.2.0670
 ===========================================================
 Date: 17.06.2026
 Severity: Medium
 CVE: *requested, not yet assigned*
 CWE: Out-of-bounds Read (CWE-125)

 ## Summary

 `get_text_props()` in `src/textprop.c` reads a `uint16` property count
 stored
 inline after a line's text and returns it as the number of 32-byte
 `textprop_T` entries that follow.  The only check is a floor that
 guarantees
 room for a single entry; the count is never checked against the amount of
 data
 actually present.  A line that declares a large count while carrying
 little
 data causes consumers to read far past the end of the line buffer.  Such a
 line can be delivered through a crafted undo file, leading to a crash.

 ## Description

 When text properties are present, a line is stored as
 `[text][NUL][prop_count (uint16)][textprop_T ...][vtext ...]`.
 `get_text_props()` validates only that the property data is large enough
 for
 one entry and then returns `prop_count` unchanged:

 ```C
     if (propdata_len < PROP_COUNT_SIZE + sizeof(textprop_T))
     {
         iemsg(e_text_property_info_corrupted);
         return 0;
     }
     mch_memmove(&prop_count, text + textlen, PROP_COUNT_SIZE);
     *props = text + textlen + PROP_COUNT_SIZE;
     return (int)prop_count;
 ```

 Consumers use the returned count as a loop bound, reading
 `sizeof(textprop_T)` (32) bytes per iteration with no re-check against the
 real
 line length, so a count of 65535 against a single stored entry reads about
 two
 megabytes past the line.  An attacker authors both a source file and its
 sibling undo (`.un~`) file; the saved line text in the undo file is
 patched so
 that, on undo, the restored line declares a property count far larger than
 its
 data.  The next consumer, such as `prop_list()` or a screen redraw, then
 reads
 out of bounds.  The same unbounded count is used by the unpacked-memline
 path
 and by the line-deletion code, which are affected in the same way.

 ## Impact

 Undo files are normally trusted data written by Vim itself, but Vim reads
 a
 sibling `.un~` file when `'undofile'` is enabled and the file's content
 hash
 matches, so a repository or archive that ships a malicious source/undo
 pair can
 deliver the crafted line.  The trigger is user-interaction-gated:
 `'undofile'`
 must be enabled, the user must open the file and undo, and a consumer must
 then
 inspect the line (for example by displaying it).  When that happens, the
 out-of-bounds read can leak adjacent memory through property metadata
 returned
 by `prop_list()` and crash the editor.

 ## Acknowledgements

 The Vim project would like to thank Cipher / Causal Security
 (https://causalsecurity.com/) for reporting and analyzing the issue and
 suggesting a fix.

 ## References

 The issue has been fixed as of Vim patch
 [v9.2.0670](https://github.com/vim/vim/releases/tag/v9.2.0670).
 -
 [Commit](https://github.com/vim/vim/commit/b2338ca90643e2f01ecb6547c1172716aaec4f79)
 - [Github Security
 Advisory](https://github.com/vim/vim/security/advisories/GHSA-f36c-2qcp-
 7gpw)
 }}}


 {{{
 Out-of-bounds Read with libsodium-encrypted Files in Vim < 9.2.0671
 ===================================================================
 Date: 17.06.2026
 Severity: Medium
 CVE: *requested, not yet assigned*
 CWE: Integer Underflow (CWE-191), Out-of-bounds Read (CWE-125)

 ## Summary

 When Vim opens a file encrypted with the `VimCrypt~04!` or `VimCrypt~05!`
 method (xchacha20poly1305, requires the `+sodium` feature) whose body is
 shorter
 than a single libsodium secretstream header, an unsigned length
 calculation
 underflows and a subsequent decryption call reads far past the end of the
 input
 buffer, crashing Vim.

 ## Description

 `crypt_get_header_len()` validates only the size of the file header
 (magic,
 salt and seed), not the length of the encrypted body that follows.  A file
 with
 a complete header but a body of 1 to 23 bytes therefore passes the size
 check.
 In `crypt_sodium_buffer_decode()` the secretstream header length is then
 subtracted from the body length:

 ```C
     from += crypto_secretstream_xchacha20poly1305_HEADERBYTES;
     len  -= crypto_secretstream_xchacha20poly1305_HEADERBYTES;
 ```

 `len` is a `size_t`, so when the body is shorter than `HEADERBYTES` the
 subtraction wraps around to a value close to the maximum.  The wrapped
 length is
 then passed to `crypto_secretstream_xchacha20poly1305_pull()`, which reads
 that
 many bytes from the input buffer.  Because the output buffer was already
 allocated using the original (small) body length, the corrupted length
 widens
 the read rather than a write, resulting in an out-of-bounds read and a
 crash.

 ## Impact

 An attacker who can get a victim to open a crafted, ostensibly encrypted
 file
 and enter any key at the prompt can reliably crash Vim (denial of
 service).  No
 information is disclosed: the decryption call faults on the over-read and
 never
 returns plaintext, and the message authentication would fail in any case.
 Exploitation requires the `+sodium` feature, user interaction to open the
 file
 and supply a key, and is limited to a crash.

 ## Acknowledgements

 The Vim project would like to thank Cipher / Causal Security
 (https://causalsecurity.com/) for reporting and analyzing the issue and
 suggesting a fix.

 ## References

 The issue has been fixed as of Vim patch
 [v9.2.0671](https://github.com/vim/vim/releases/tag/v9.2.0671).
 -
 [Commit](https://github.com/vim/vim/commit/c8777cec25dcfae89c42e9aff51af61f71c5745f)
 - [Github Security
 Advisory](https://github.com/vim/vim/security/advisories/GHSA-
 c4j9-wr9j-4486)
 }}}
-- 
Ticket URL: <https://wiki.linuxfromscratch.org/lfs/ticket/5956#comment:1>
LFS Trac <https://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-book
Unsubscribe: See the above information page