Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Feb 2026 03:59:38 +0000
From:      Adam Weinberger <adamw@FreeBSD.org>
To:        ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org
Subject:   git: 0646ec8a67e8 - main - editors/vim: Update to 9.2.0073, multiple security fixes
Message-ID:  <69a2682a.32cd9.25156fb8@gitrepo.freebsd.org>

index | next in thread | raw e-mail

The branch main has been updated by adamw:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0646ec8a67e8741ff56f9f9d47346466e047948f

commit 0646ec8a67e8741ff56f9f9d47346466e047948f
Author:     Adam Weinberger <adamw@FreeBSD.org>
AuthorDate: 2026-02-28 03:49:16 +0000
Commit:     Adam Weinberger <adamw@FreeBSD.org>
CommitDate: 2026-02-28 03:59:34 +0000

    editors/vim: Update to 9.2.0073, multiple security fixes
    
    While the minor has bumped, and much has changed from 9.1 to 9.2,
    we've been incrementally adopting the patches so it's not "new" to us,
    per se. All the gory details are at:
      https://github.com/vim/vim/blob/master/runtime/doc/version9.txt
    
    This commit adds patches for six security issues:
    
    patch 9.2.0073: [security]: possible command injection using netrw
    Problem:  [security]: Insufficient validation of hostname and port in
              netrw URIs allows command injection via shell metacharacters
              (ehdgks0627, un3xploitable).
    Solution: Implement stricter RFC1123 hostname and IP validation.
              Use shellescape() for the provided hostname and port.
    
    Github Advisory:
    GHSA-m3xh-9434-g336
    
    patch 9.2.0074: [security]: Crash with overlong emacs tag file
    Problem:  Crash with overlong emacs tag file, because of an OOB buffer
              read (ehdgks0627, un3xploitable)
    Solution: Check for end of buffer and return early.
    
    Github Advisory:
    GHSA-h4mf-vg97-hj8j
    
    patch 9.2.0075: [security]: Buffer underflow with emacs tag file
    Problem:  When parsing a malformed Emacs-style tags file, a 1-byte
              heap-buffer-underflow read occurs if the 0x7f delimiter
              appears at the very beginning of a line. This happens
              because the code attempts to scan backward for a tag
              name from the delimiter without checking if space exists.
              (ehdgks0627, un3xploitable)
    Solution: Add a check to ensure the delimiter (p_7f) is not at the
              start of the buffer (lbuf) before attempting to isolate
              the tag name.
    
    GitHub Advisory:
    GHSA-xcc8-r6c5-hvwv
    
    patch 9.2.0076: [security]: buffer-overflow in terminal handling
    Problem:  When processing terminal output with many combining characters
              from supplementary planes (4-byte UTF-8), a heap-buffer
              overflow occurs. Additionally, the loop iterating over
              cell characters can read past the end of the vterm array
              (ehdgks0627, un3xploitable).
    Solution: Use VTERM_MAX_CHARS_PER_CELL * 4 for ga_grow() to ensure
              sufficient space. Add a boundary check to the character
              loop to prevent index out-of-bounds access.
    
    Github Advisory:
    GHSA-rvj2-jrf9-2phg
    
    patch 9.2.0077: [security]: Crash when recovering a corrupted swap file
    Problem:  memline: a crafted swap files with bogus pe_page_count/pe_bnum
              values could cause a multi-GB allocation via mf_get(), and
              invalid pe_old_lnum/pe_line_count values could cause a SEGV
              when passed to readfile() (ehdgks0627, un3xploitable)
    Solution: Add bounds checks on pe_page_count and pe_bnum against
              mf_blocknr_max before descending into the block tree, and
              validate pe_old_lnum >= 1 and pe_line_count > 0 before calling
              readfile().
    
    Github Advisory:
    GHSA-r2gw-2x48-jj5p
    
    patch 9.2.0078: [security]: stack-buffer-overflow in build_stl_str_hl()
    Problem:  A stack-buffer-overflow occurs when rendering a statusline
              with a multi-byte fill character on a very wide terminal.
              The size check in build_stl_str_hl() uses the cell width
              rather than the byte length, allowing the subsequent fill
              loop to write beyond the 4096-byte MAXPATHL buffer
              (ehdgks0627, un3xploitable).
    Solution: Update the size check to account for the byte length of
              the fill character (using MB_CHAR2LEN).
    
    Github Advisory:
    GHSA-gmqx-prf2-8mwf
    
    Security:       Multiple (see commit message)
---
 editors/vim/Makefile | 2 +-
 editors/vim/distinfo | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/editors/vim/Makefile b/editors/vim/Makefile
index 4406951b9d55..fcee069f80ce 100644
--- a/editors/vim/Makefile
+++ b/editors/vim/Makefile
@@ -1,5 +1,5 @@
 PORTNAME=	vim
-PORTVERSION=	9.1.2148
+PORTVERSION=	9.2.0078
 DISTVERSIONPREFIX=	v
 CATEGORIES=	editors
 
diff --git a/editors/vim/distinfo b/editors/vim/distinfo
index 6e310b6fdfd6..6adf5b6e6cab 100644
--- a/editors/vim/distinfo
+++ b/editors/vim/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1771010452
-SHA256 (vim-vim-v9.1.2148_GH0.tar.gz) = f9ec31df8f1a78e130dd06c395e6626c2a8a8ec2705d8e7b7667bd3ecd499c6b
-SIZE (vim-vim-v9.1.2148_GH0.tar.gz) = 19590599
+TIMESTAMP = 1772250113
+SHA256 (vim-vim-v9.2.0078_GH0.tar.gz) = 031e56ccc745fd2db2464dbde1e232cde6ec45251a6f7253ef34deca7faed887
+SIZE (vim-vim-v9.2.0078_GH0.tar.gz) = 19754609


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69a2682a.32cd9.25156fb8>