[prev in list] [next in list] [prev in thread] [next in thread] List: oss-security Subject: [oss-security] CVE-2019-3016: information leak within a KVM guest From: John Haxby <john.haxby () oracle ! com> Date: 2020-01-30 18:00:03 Message-ID: 7151FEEF-4905-4333-8F4A-8B46AEC36E07 () oracle ! com [Download RAW message or body] [Attachment #2 (multipart/mixed)] The problem is missing TLB flushes which potentially allows a process in a KVM guest to access \ memory locations within that guest that it should not have access to. The problem is limited to host kernels 4.10 onwards with guest kernels running 4.16 onwards and \ PV TLB exposed to the guests. Additionally, the problem mainly affects AMD processors but we \ cannot rule out Intel CPUs. From the patch cover note: > The KVM hypervisor may provide a guest with ability to defer remote TLB > flush when the remote VCPU is not running. When this feature is used, > the TLB flush will happen only when the remote VPCU is scheduled to run > again. This will avoid unnecessary (and expensive) IPIs. > > Under certain circumstances, when a guest initiates such deferred action, > the hypervisor may miss the request. It is also possible that the guest > may mistakenly assume that it has already marked remote VCPU as needing a > flush when in fact that request had already been processed by the hypervisor. > In both cases this will result in an invalid translation being present in a > vCPU, potentially allowing accesses to memory locations in that guest's > address space that should not be accessible. > > Note that only intra-guest memory is vulnerable. > > The attached patches address both of these problems: > 1. The first patch makes sure the hypervisor doesn't accidentally clear > guest's remote flush request > 2. The rest of the patches prevent the race between hypervisor > acknowledging a remote flush request and guest issuing a new one. Part of the attached patches were discovered independently[1] and made public on 2019-01-16 \ although it was our considered opinion that the security implications of this were not at all \ obvious so we kept the embargo. The original patches posted to linux-distros broke ARM so I'm attaching the v2 patches. These \ will be heading to the mainline kernel shortly. jch [1] https://lore.kernel.org/kvm/20200116001635.174948-1-jmattson@google.com ["CVE-2019-3016.v2.tgz" (CVE-2019-3016.v2.tgz)] ^ <ks۶j VDD=&'qZĉ'N{;,CRv&.HI4kL"Y$ }a=VM]kW/: \ oc`<0}C7,C=ðzf}e8c \ 8oZWT?\= (._Թ/&pwe~i F00\2 \ u|4O^k9 9c莇ݑg849_0ct1VSA0Y1{ hai9kn8p~-y&{^1Cf֡gm |9!wfW&3ZˀBMDhkKm+ > r9<~c:1(A ϋxx\SN(q|vbhxٵ͝Ke_A \ > .ۣS <6 #LkNqXǗs8 tL4Ey?wp XQ{j8Cv愳&|b,zq:+QirU|˯|~ /Sw͵]jtgK?.=>)Șm]Q/@sAdN{f \ 0y|o'>_byC״x0X U``?}T!k㗡3xB4d'=rlq܆5NZbK*0 \ Z\LݎBeGVŧN} jh \ K-lpɥ(V >