| Summary: | <sys-fs/lvm2-2.02.187: heap memory leak (CVE-2020-8991) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | filip ambroz <filip.ambroz> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | agk, base-system, marci_r, robbat2 |
| Priority: | Normal | Keywords: | CC-ARCHES |
| Version: | unspecified | Flags: | nattka:
sanity-check+
|
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://nvd.nist.gov/vuln/detail/CVE-2020-8991 | ||
| Whiteboard: | A3 [noglsa cve] | ||
| Package list: |
sys-fs/lvm2-2.02.187-r2 amd64 arm arm64 hppa ppc ppc64 s390 sparc x86
|
Runtime testing required: | --- |
| Deadline: | 2020-04-19 | ||
References: https://sourceware.org/git/?p=lvm2.git;a=commit;h=bcf9556b8fcd16ad8997f80cc92785f295c66701 commit b8b99da05953052a27440192953e417e07965fb6 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Thu Mar 26 21:05:18 2020 sys-fs/lvm2: Bump to version 2.02.187 Package-Manager: Portage-2.3.96, Repoman-2.3.22 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> This release contains the fix. Will call stabilization in a couple of days unless some severe regressions pop up. I'll do a rev bump later with some fixes for runscript before we stabilize. Just in case anyone worries about this one, nobody has provided upstream with any evidence of a security problem here so the upstream view remains that the CVE designation was a mistake. But do still fix the bug to improve stability if you're using the affected features. I updated runscript, let's wait a few days. amd64 stable x86 stable s390 stable arm stable sparc stable ppc stable ppc64 stable hppa stable (In reply to Alasdair Kergon from comment #4) > Just in case anyone worries about this one, nobody has provided upstream > with any evidence of a security problem here so the upstream view remains > that the CVE designation was a mistake. > > But do still fix the bug to improve stability if you're using the affected > features. I did mean to reply at the time -- thank you for clarifying. I was a bit dubious when I saw it. I'll tentatively set glsa? because I can't vote yet. arm64 stable: https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-fs/lvm2?id=7a37c9c92fd70ccad519e68ae2726ff91f5e186e @maintainer(s), please cleanup The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1881836d0d33dcd9636e8ce903e3f4c46ef01f3f commit 1881836d0d33dcd9636e8ce903e3f4c46ef01f3f Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-04-27 00:46:57 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-04-27 00:49:24 +0000 sys-fs/lvm2: security cleanup Bug: https://bugs.gentoo.org/709686 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-fs/lvm2/Manifest | 2 - sys-fs/lvm2/files/lvm.rc-2.02.184-r3 | 154 ------------------- sys-fs/lvm2/lvm2-2.02.184-r5.ebuild | 273 ---------------------------------- sys-fs/lvm2/lvm2-2.02.186-r2.ebuild | 279 ----------------------------------- sys-fs/lvm2/lvm2-2.02.187.ebuild | 279 ----------------------------------- 5 files changed, 987 deletions(-) Closing without GLSA due to dispute. |
from URLs: vg_lookup in daemons/lvmetad/lvmetad-core.c in LVM2 2.02 mismanages memory, leading to an lvmetad memory leak, as demonstrated by running pvs: #!/bin/bash while : do pvs sleep 1 done use top command to watch RES memory of lvmetad. After a few minutes, its RES memory will grow for a few KB. Then stop calling pvs, while its RES will not decrease. This is because, when lvmetad make reponse for clent request, it will malloc new chunk for s->vgid_to_metadata, while actually the new chunk should be added to the reponse dm_config_tree, or it will make the chunk list of s->vgid_to_metadata keep growing.