| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in GitLab Community and Enterprise Edition through 12.4. It has Insecure Permissions (issue 4 of 4). |
| An issue was discovered in GitLab Community and Enterprise Edition 11.3 through 12.4. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition 11.3 through 12.3 when a sub group epic is added to a public group. It has Incorrect Access Control. |
| An issue was discovered in GitLab Community and Enterprise Edition 8.15 through 12.4 in the Comments Search feature provided by the Elasticsearch integration. It has Incorrect Access Control. |
| An issue was discovered in GitLab Community and Enterprise Edition 11.3 to 12.3 in the protected environments feature. It has Insecure Permissions (issue 3 of 4). |
| An issue was discovered in GitLab Community and Enterprise Edition through 12.4. It has Insecure Permissions (issue 2 of 4). |
| An issue was discovered in GitLab Community and Enterprise Edition 11.8 through 12.4 when handling Security tokens.. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition 8.17 through 12.4 in the Search feature provided by Elasticsearch integration.. It has Insecure Permissions (issue 1 of 4). |
| An issue was discovered in GitLab Community and Enterprise Edition 11 through 12.4 when building Nested GraphQL queries. It has a large or infinite loop. |
| An issue was discovered in GitLab Community and Enterprise Edition 10.5 through 12.4 in link validation for RDoc wiki pages feature. It has XSS. |
| An issue was discovered in GitLab Community and Enterprise Edition 11.6 through 12.4 in the add comments via email feature. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition 11.3 through 12.4 when moving an issue to a public project from a private one. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition 10.7.4 through 12.4 in the InternalRedirect filtering feature. It has an Open Redirect. |
| An issue was discovered in GitLab Community and Enterprise Edition before 12.4 in the Project labels feature. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition before 12.4 in the autocomplete feature. It has Insecure Permissions (issue 2 of 2). |
| An issue was discovered in GitLab Community and Enterprise Edition before 12.4. It has Incorrect Access Control. |
| An issue was discovered in GitLab Community and Enterprise Edition before 12.4. It has Insecure Permissions. |
| An issue was discovered in GitLab Community and Enterprise Edition 8.15 through 12.4. It has Insecure Permissions (issue 1 of 2). |
| An issue was discovered in Xen through 4.12.x allowing 32-bit PV guest OS users to gain guest OS privileges by installing and using descriptors. There is missing descriptor table limit checking in x86 PV emulation. When emulating certain PV guest operations, descriptor table accesses are performed by the emulating code. Such accesses should respect the guest specified limits, unless otherwise guaranteed to fail in such a case. Without this, emulation of 32-bit guest user mode calls through call gates would allow guest user mode to install and then use descriptors of their choice, as long as the guest kernel did not itself install an LDT. (Most OSes don't install any LDT by default). 32-bit PV guest user mode can elevate its privileges to that of the guest kernel. Xen versions from at least 3.2 onwards are affected. Only 32-bit PV guest user mode can leverage this vulnerability. HVM, PVH, as well as 64-bit PV guests cannot leverage this vulnerability. Arm systems are unaffected. |
| An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device. This occurs because passed through PCI devices may corrupt host memory after deassignment. When a PCI device is assigned to an untrusted domain, it is possible for that domain to program the device to DMA to an arbitrary address. The IOMMU is used to protect the host from malicious DMA by making sure that the device addresses can only target memory assigned to the guest. However, when the guest domain is torn down, or the device is deassigned, the device is assigned back to dom0, thus allowing any in-flight DMA to potentially target critical host data. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. |
