Date: Mon, 20 Jul 2020 14:44:48 +0100 From: Andrew Cooper <andrew.cooper3@...rix.com> To: Mauro Matteo Cascella <mcascell@...hat.com>, <oss-security@...ts.openwall.com> CC: <xen-announce@...ts.xen.org>, <xen-devel@...ts.xen.org>, <xen-users@...ts.xen.org>, Xen.org security team <security-team-members@....org> Subject: Re: Xen Security Advisory 329 v2 - Linux ioperm bitmap context switching issues /sigh - it seems that stuff like this doesn't get done when I'm on holiday. I'll get one sorted. ~Andrew On 17/07/2020 08:54, Mauro Matteo Cascella wrote: > Hello, > > Will a CVE be assigned to this flaw? > > Thanks, > > On Thu, Jul 16, 2020 at 3:21 PM Xen.org security team <security@....org <mailto:security@....org>> wrote: > > Xen Security Advisory XSA-329 > version 2 > > Linux ioperm bitmap context switching issues > > UPDATES IN VERSION 2 > ==================== > > Public release. > > ISSUE DESCRIPTION > ================= > > Linux 5.5 overhauled the internal state handling for the iopl() and > ioperm() > system calls. Unfortunately, one aspect on context switch wasn't wired up > correctly for the Xen PVOps case. > > IMPACT > ====== > > IO port permissions don't get rescinded when context switching to an > unprivileged task. Therefore, all userspace can use the IO ports > granted to > the most recently scheduled task with IO port permissions. > > VULNERABLE SYSTEMS > ================== > > Only x86 guests are vulnerable. > > All versions of Linux from 5.5 are potentially vulnerable. > > Linux is only vulnerable when running as x86 PV guest. Linux is not > vulnerable when running as an x86 HVM/PVH guests. > > The vulnerability can only be exploited in domains which have been granted > access to IO ports by Xen. This is typically only the hardware > domain, and > guests configured with PCI Passthrough. > > MITIGATION > ========== > > Running only HVM/PVH guests avoids the vulnerability. > > CREDITS > ======= > > This issue was discovered by Andy Lutomirski. > > RESOLUTION > ========== > > Applying the appropriate attached patch resolves this issue. > > xsa329.patch Linux 5.5 and later > > $ sha256sum xsa329* > cdb5ac9bfd21192b5965e8ec0a1c4fcf12d0a94a962a8158cd27810e6aa362f0 > xsa329.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 > > > > -- > Mauro Matteo Cascella, Red Hat Product Security > 6F78 E20B 5935 928C F0A8 1A9D 4E55 23B8 BB34 10B0
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.