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. Reference and upstream commit: https://sourceware.org/git/?p=lvm2.git;a=commit;h=bcf9556b8fcd16ad8997f80cc92785f295c66701
Created lvm2 tracking bugs for this issue: Affects: fedora-all [bug 1805925]
Please can someone ask the person who granted the CVE to update the description to provide a detailed explanation of the vulnerability? The current description does not tell me anything useful. lvmetad is a non-critical optional system component that caches metadata to assist LVM commands run by the root user. The daemon is not supposed to be network-accessible so what has been found that counts as 'AV:N' (network attack vector)? Only local root users can communicate with it in its standard configuration, so what has been found that counts as PR:N (no privilege required)? Without additional information to fill the gaps, then I believe the CVE classification for this bug was a mistake and should be withdrawn.
I would challenge 'A:H' (high impact on availability) too. The system's I/O flows through device-mapper not lvm2. The role of lvm2 is to change the configuration of those device-mapper I/O flows and, as lvmetad is an optional caching layer within lvm2, you (and the system) are always free to kill or disable or bypass it with minimal impact.
I couldn't find who assigned this CVE, probably was Mitre itself by someone's request trough their web form. The CVSS score was set by NVD and they assume the worst case scenario, after analysis our team can (and probably will) send a request for a rescore. If you want to contest an already public CVE, you can contact Mitre using this link[1], and choose the "request an update", then "rejection" type. [1]. https://cveform.mitre.org/
Statement: The lvm2 package as shipped with Red Hat Enterprise Linux 8 is not affected as it doesn't contains the affected component (lvmetad).
(In reply to Guilherme de Almeida Suckevicz from comment #4) > If you want to contest an already public CVE, you can contact Mitre using > this link[1], and choose the "request an update", then "rejection" type. > [1]. https://cveform.mitre.org/ I have submitted such a response.
Mitre has marked it as disputed in response to my submissions: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8991 If anyone does possess information about why this should still count as a vulnerability, please make this known.