Lookup for vulnerable packages by Package URL.
| Purl | pkg:apk/alpine/xen@4.13.1-r4?arch=armhf&distroversion=v3.17&reponame=main |
|---|
| Type | apk |
|---|
| Namespace | alpine |
|---|
| Name | xen |
|---|
| Version | 4.13.1-r4 |
|---|
| Qualifiers |
| arch |
armhf |
| distroversion |
v3.17 |
| reponame |
main |
|
|---|
| Subpath | |
|---|
| Is_vulnerable | false |
|---|
| Next_non_vulnerable_version | 4.13.1-r5 |
|---|
| Latest_non_vulnerable_version | 4.16.6-r3 |
|---|
| Affected_by_vulnerabilities |
|
|---|
| Fixing_vulnerabilities |
| 0 |
| url |
VCID-66yt-mbde-wbar |
| vulnerability_id |
VCID-66yt-mbde-wbar |
| summary |
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs, a CPU cache also needs writing back to memory after changes were made. Such writing back of cached data was missing in particular when splitting large page mappings into smaller granularity ones. A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. Xen versions from at least 3.2 onwards are affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
|
| 16 |
|
|
| fixed_packages |
|
| aliases |
CVE-2020-15565, XSA-321
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-66yt-mbde-wbar |
|
| 1 |
| url |
VCID-p7cw-6jy5-cuct |
| vulnerability_id |
VCID-p7cw-6jy5-cuct |
| summary |
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1) will be considered an error. All the other cases will provide a valid port and will result in a crash when trying to access the event channel. When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and later are affected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event-channel limit. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
|
|
| fixed_packages |
|
| aliases |
CVE-2020-15566, XSA-317
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-p7cw-6jy5-cuct |
|
| 2 |
| url |
VCID-t63m-cstk-2khv |
| vulnerability_id |
VCID-t63m-cstk-2khv |
| summary |
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Xen versions from 4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected. Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In addition, there needs to be an entity actively monitoring a guest's video frame buffer (typically for display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests, as well as x86 HVM guests using hardware assisted paging (HAP), cannot leverage the vulnerability. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
|
|
| fixed_packages |
|
| aliases |
CVE-2020-15563, XSA-319
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-t63m-cstk-2khv |
|
|
|---|
| Risk_score | null |
|---|
| Resource_url | http://public2.vulnerablecode.io/packages/pkg:apk/alpine/xen@4.13.1-r4%3Farch=armhf&distroversion=v3.17&reponame=main |
|---|