unsubscribe from predisclosure list

[Information Security Access <security@xxxxxxxx>]

Hi Xen-Team,

can you please unsubscrbe security@xxxxxxxx from your predisclosure list.

We as company 1&1 Telecommunication SE do not use Xen projects anymore.

So a dedicated predisclosure information is not needed.

Thanks,

Information Securtiy Access

1&1 Telecommunication SE
Elgendorfer Str. 57
56410 Montabaur
Germany

Website: https://www.1und1.de/

Am 28.05.2026 um 23:11 schrieb Xen.org security team:

>             Xen Security Advisory
>       CVE-2026-42487 / XSA-491
>       
>                           x86 HVM I/O port list traversal
>       
>                     *** EMBARGOED UNTIL 2026-06-09 12:00 UTC ***
>       
>       ISSUE DESCRIPTION
>       =================
>       
>       HVM guest I/O port accesses are subject to either emulation or at
>       least
>       translation.  Translations are managed by the device model (via
>       XEN_DOMCTL_ioport_mapping), and hence the linked list used may
>       changed
>       at any time.  Traversal of those lists (while handling guest I/O
>       port
>       accesses) therefore needs synchronizing with updates, which was
>       missing
>       so far.
>       
>       IMPACT
>       ======
>       
>       A device model of a HVM guest can cause a hypervisor crash,
>       causing a
>       Denial of Service (DoS) of the entire host.  Privilege escalation
>       and
>       information leaks cannot be ruled out.
>       
>       VULNERABLE SYSTEMS
>       ==================
>       
>       All Xen versions from at least 3.2 onwards are vulnerable. 
>       Earlier
>       versions have not been inspected.
>       
>       Only x86 systems are vulnerable.  Arm systems are not vulnerable.
>       
>       Only entities controlling HVM guests can leverage the
>       vulnerability.
>       These are device models running in either a stub domain or
>       de-privileged
>       in Dom0.
>       
>       MITIGATION
>       ==========
>       
>       Running only PV or PVH guests will avoid the vulnerability.
>       
>       (Switching from a device model stub domain or a de-privileged
>       device
>       model to a fully privileged Dom0 device model does NOT mitigate
>       this
>       vulnerability.  Rather, it simply recategorises the vulnerability
>       to
>       hostile management code, regarding it "as designed"; thus it
>       merely
>       reclassifies these issues as "not a bug".  The security of a Xen
>       system
>       using stub domains is still better than with a qemu-dm running as
>       a Dom0
>       process.  Users and vendors of stub qemu dm systems should not
>       change
>       their configuration to use a Dom0 qemu process.)
>       
>       CREDITS
>       =======
>       
>       This issue was discovered by Jan Beulich of SUSE.
>       
>       RESOLUTION
>       ==========
>       
>       Applying the appropriate attached patch resolves this issue.
>       
>       Note that patches for released versions are generally prepared to
>       apply to the stable branches, and may not apply cleanly to the
>       most
>       recent release tarball.  Downstreams are encouraged to update to
>       the
>       tip of the stable branch before applying these patches.
>       
>       xsa491.patch           xen-unstable
>       xsa491-4.21.patch      Xen 4.21.x - Xen 4.17.x
>       
>       $ sha256sum xsa491*
>       23a90da1c71389083351846169fc565a671b44f5f4ba838b18fc0fa6d7582bf8 
>       xsa491.patch
>       443674f42a092b953b6ba4d91cfa19bfbee0077dfcd5a39ae53368e40ed23aac 
>       xsa491-4.21.patch
>       $
>       
>       DEPLOYMENT DURING EMBARGO
>       =========================
>       
>       Deployment of the patches and/or mitigations described above (or
>       others which are substantially similar) is permitted during the
>       embargo, even on public-facing systems with untrusted guest users
>       and
>       administrators.
>       
>       But: Distribution of updated software is prohibited (except to
>       other
>       members of the predisclosure list).
>       
>       Predisclosure list members who wish to deploy significantly
>       different
>       patches and/or mitigations, please contact the Xen Project
>       Security
>       Team.
>       
>       (Note: this during-embargo deployment notice is retained in
>       post-embargo publicly released Xen Project advisories, even though
>       it
>       is then no longer applicable.  This is to enable the community to
>       have
>       oversight of the Xen Project Security Team's decisionmaking.)
>       
>       For more information about permissible uses of embargoed
>       information,
>       consult the Xen Project community's agreed Security Policy:
>         http://www.xenproject.org/security-policy.html
>