From ${URL} : libvterm through 0+bzr726, as used in Vim and other products, mishandles certain out-of-memory conditions, leading to a denial of service (application crash), related to screen.c, state.c, and vterm.c. Upstream Issue: https://github.com/vim/vim/issues/3711 Upstream Patch: https://github.com/vim/vim/commit/cd929f7ba8cc5b6d6dcf35c8b34124e969fed6b8 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
(In reply to Agostino Sarubbo from comment #0) > libvterm through 0+bzr726, as used in Vim and other products, mishandles > certain > out-of-memory conditions, leading to a denial of service (application crash), > related to screen.c, state.c, and vterm.c. I haven't been able to identify the specific fix with 100% confidence, although there have been OOM and memory leak related commits, such as https://bazaar.launchpad.net/~libvterm/libvterm/trunk/revision/756. @maintainer(s), my recommendation is to bump to the latest, or preferably take a snapshot from the website to guarantee all of these fixes are included, even if not related to this specific vulnerability. It looks like there is another vulnerability disclosed here: https://bugs.launchpad.net/libvterm/+bug/1846869 > Upstream Patch: > https://github.com/vim/vim/commit/cd929f7ba8cc5b6d6dcf35c8b34124e969fed6b8 > Note that this was fixed in vim v8.1.0633.
Tree is clean.
(In reply to sam_c (Security Padawan) from comment #2) > Tree is clean. No, ignore this! Still needs a bump as per my previous comment.
(In reply to Sam James (sec padawan) from comment #1) > (In reply to Agostino Sarubbo from comment #0) > > libvterm through 0+bzr726, as used in Vim and other products, mishandles > > certain > > out-of-memory conditions, leading to a denial of service (application crash), > > related to screen.c, state.c, and vterm.c. > > I haven't been able to identify the specific fix with 100% confidence, > although there have been OOM and memory leak related commits, such as > https://bazaar.launchpad.net/~libvterm/libvterm/trunk/revision/756. > > @maintainer(s), my recommendation is to bump to the latest, or preferably > take a snapshot from the website to guarantee all of these fixes are > included, even if not related to this specific vulnerability. @maintainer(s), ping
Launchpad bug seems to say this is fixed in dev-libs/libvterm-0.1.2. According to Sam this is fixed a long time ago in Vim. Still appear vulnerable in dev-libs/libvterm-neovim (patch: https://github.com/neovim/libvterm/commit/4a5fa43e0dbc0db4fe67d40d788d60852864df9e). Maybe we should last rite that? Where else is this bundled?
Concerning this bug, libvterm seems to have long been clean but libvterm-neovim is seems still vulnerable and also not used by anything (neovim uses libvterm, the neovim fork upstream is dead). See also: https://github.com/neovim/neovim/wiki/Deps#forks Thus I propose to last-rite dev-libs/libvterm-neovim.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75225a6aa187a843d1c9f21fa871730e404d30d0 commit 75225a6aa187a843d1c9f21fa871730e404d30d0 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-06-19 02:58:00 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-06-19 02:59:27 +0000 profiles: last rite dev-libs/libvterm-neovim Bug: https://bugs.gentoo.org/678750 Signed-off-by: John Helmert III <ajak@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
(In reply to 9ts641j2 from comment #6) > Concerning this bug, libvterm seems to have long been clean but > libvterm-neovim is seems still vulnerable and also not used by anything > (neovim uses libvterm, the neovim fork upstream is dead). See also: > https://github.com/neovim/neovim/wiki/Deps#forks > Thus I propose to last-rite dev-libs/libvterm-neovim. Thanks! Same maintainer, same vulnerability, and no GLSA, so I think we can safely reuse this bug.
Removed and noglsa. All done.
