Lookup for vulnerable packages by Package URL.
| Purl | pkg:apk/alpine/xen@4.14.5-r0?arch=mips64&distroversion=v3.13&reponame=main |
|---|
| Type | apk |
|---|
| Namespace | alpine |
|---|
| Name | xen |
|---|
| Version | 4.14.5-r0 |
|---|
| Qualifiers |
| arch |
mips64 |
| distroversion |
v3.13 |
| reponame |
main |
|
|---|
| Subpath | |
|---|
| Is_vulnerable | false |
|---|
| Next_non_vulnerable_version | 4.14.5-r1 |
|---|
| Latest_non_vulnerable_version | 4.14.5-r7 |
|---|
| Affected_by_vulnerabilities |
|
|---|
| Fixing_vulnerabilities |
| 0 |
| url |
VCID-5wye-y63w-syff |
| vulnerability_id |
VCID-5wye-y63w-syff |
| summary |
Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
|
| fixed_packages |
|
| aliases |
CVE-2022-26356, XSA-397
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-5wye-y63w-syff |
|
| 1 |
| url |
VCID-63u8-8gxf-7kf8 |
| vulnerability_id |
VCID-63u8-8gxf-7kf8 |
| summary |
grant table v2 status pages may remain accessible after de-allocation (take two) Guest get permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the guest to insert mappings of these pages may result in any of them to become mapped in multiple locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps re-used for other purposes. This bug was fortuitously fixed by code cleanup in Xen 4.14, and backported to security-supported Xen branches as a prerequisite of the fix for XSA-378. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2021-28703, XSA-387
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-63u8-8gxf-7kf8 |
|
| 2 |
|
| 3 |
|
| 4 |
| url |
VCID-ggdu-ttwp-vyev |
| vulnerability_id |
VCID-ggdu-ttwp-vyev |
| summary |
guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It would then only be the overflowed (and hence small) number which gets compared against the established upper bound. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2021-28706, XSA-385
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-ggdu-ttwp-vyev |
|
|
|---|
| Risk_score | null |
|---|
| Resource_url | http://public2.vulnerablecode.io/packages/pkg:apk/alpine/xen@4.14.5-r0%3Farch=mips64&distroversion=v3.13&reponame=main |
|---|