Out-of-Bounds Affecting xen package, versions <4.14.0-r1


0.0
medium

Snyk CVSS

    Attack Complexity Low
    Scope Changed
    Availability High

    Threat Intelligence

    EPSS 0.05% (14th percentile)
Expand this section
NVD
6.5 medium
Expand this section
SUSE
6.5 medium

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk ID SNYK-ALPINE315-XEN-1929213
  • published 24 Sep 2020
  • disclosed 23 Sep 2020

How to fix?

Upgrade Alpine:3.15 xen to version 4.14.0-r1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream xen package and not the xen package as distributed by Alpine. See How to fix? for Alpine:3.15 relevant fixed versions and status.

An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable.