Summary: | <dev-libs/libvterm-0.1.2 dev-libs/libvterm-neovim: out-of-memory in screen.c, state.c, vterm.c leading to denial of service | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | vim |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1680588 | ||
Whiteboard: | B3 [noglsa] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2019-02-25 15:16:01 UTC
(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. |