* [Xen-devel] Xen Security Advisory 307 v3 (CVE-2019-19581, CVE-2019-19582) - find_next_bit() issues
@ 2019-12-11 12:05 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2019-12-11 12:05 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2019-19581,CVE-2019-19582 / XSA-307
version 3
find_next_bit() issues
UPDATES IN VERSION 3
====================
Public release.
Updated metadata to add 4.13, update StableRef's
ISSUE DESCRIPTION
=================
In a number of places bitmaps are being used by the hypervisor to track
certain state. Iteration over all bits involves functions which may
misbehave in certain corner cases:
- - On 32-bit Arm accesses to bitmaps with bit a count which is a multiple
of 32, an out of bounds access may occur. (CVE-2019-19581)
- - On x86 accesses to bitmaps with a compile time known size of 64 may
incur undefined behavior, which may in particular result in infinite
loops. (CVE-2019-19582)
IMPACT
======
A malicious guest may cause a hypervisor crash or hang, resulting in a
Denial of Service (DoS).
VULNERABLE SYSTEMS
==================
All versions of Xen are vulnerable.
32-bit Arm systems are vulnerable.
x86 systems with 64 or more nodes are vulnerable. We are unaware of any
such systems that Xen would run on.
64-bit Arm systems as well as x86 systems with less than 64 nodes are
not vulnerable.
MITIGATION
==========
There is no known mitigation for 32-bit Arm systems.
For x86 systems the issue can be avoided by suppressing the use of NUMA
information provided by firmware, via the "numa=off" command line
option.
RESOLUTION
==========
Applying the attached patch resolves this issue.
xsa307.patch xen-unstable, Xen 4.13.x ... 4.8.x
$ sha256sum xsa307*
e589e96a0b3ec66f1d2d6393b82fab13ed18fd9fb112044a12263336b8499c68 xsa307.meta
7df052768cc05329bc44bf724897227885da8bb2cde9ff01d0ba2a34611bde97 xsa307.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
-----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl3w24gMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZxokH/2bGTmGUZP0tyc+oDHjlrr3+FarhoJnRTl4EoqJS
hzsa5OkcqzcEgrQ+7VL7dLW3AboT2zcx2RQ9HyxCz61BfDY1XF8EDDr6chJiNofN
J7OGirNzSBHFFQJOc2KFG8al+1F8WzzKP3UMbqNBrqB07/tQc5lttdbA/t5Tnp9c
xreCAkkBscDk1LFR8HiUA3YeykiHQtF09O+VnxXO2AD/Dpo8e+K6AmJkCZ4+ysNP
JKMc13vQ3UKjMmYzgbuNCIswNu1Wy3EnNZMf2zvGIhuw6iN6vSJJgoz0OSPUb4yY
kXEe1dlgseSbMxXEqj4IyZ69pEw6Ijj+H6PybQo/IOie7q0=
=7XWU
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa307.meta --]
[-- Type: application/octet-stream, Size: 1779 bytes --]
{
"XSA": 307,
"SupportedVersions": [
"master",
"4.13",
"4.12",
"4.11",
"4.10",
"4.9",
"4.8"
],
"Trees": [
"xen"
],
"Recipes": {
"4.10": {
"Recipes": {
"xen": {
"StableRef": "e4899550ff7834e1ea5dfbbfb1c618f64e247761",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"4.11": {
"Recipes": {
"xen": {
"StableRef": "239d37e514c93e29d50d71f734b1dc453b2236a6",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"4.12": {
"Recipes": {
"xen": {
"StableRef": "212b8500cb394b3a664655f79ca0bdcb31246ff7",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"4.13": {
"Recipes": {
"xen": {
"StableRef": "fd9bfabf69ea59f2280c1703500793fa15e81956",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"4.8": {
"Recipes": {
"xen": {
"StableRef": "a260e93db794f560502e89859aaf111d178e80e4",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"4.9": {
"Recipes": {
"xen": {
"StableRef": "8d1ee9f2c473fec54b5018c01ad556d7afd62c17",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
},
"master": {
"Recipes": {
"xen": {
"StableRef": "b73aad4c8b6a767ce15cc8cb65f9eeab7bfccdae",
"Prereqs": [],
"Patches": [
"xsa307.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa307.patch --]
[-- Type: application/octet-stream, Size: 4152 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86+Arm32: make find_next_{,zero_}bit() have well defined behavior
These functions getting used with the 2nd and 3rd arguments being equal
wasn't well defined: Arm64 reliably returns the value of the 2nd
argument in this case, while on x86 for bitmaps up to 64 bits wide the
return value was undefined (due to the undefined behavior of a shift of
a value by the number of bits it's wide) when the incoming value was 64.
On Arm32 an actual out of bounds access would happen when the
size/offset value is a multiple of 32; if this access doesn't fault, the
return value would have been sufficiently correct afaict.
Make the functions consistently tolerate the last two arguments being
equal (and in fact the 3rd argument being greater or equal to the 2nd),
in favor of finding and fixing all the use sites that violate the
original more strict assumption.
This is XSA-307.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien@xen.org>
---
The most obvious (albeit still indirect) exposure to guests is
evtchn_check_pollers(), which imo makes this a security issue at least
for Arm32.
This was originally already discussed between (at least) Andrew and me,
and I don't really recall who brought up the issue first.
Note that Arm's Linux origin of the code may call for syncing
publication with them. Then again I don't want to tell them just to see
them go public ahead of us.
--- a/xen/arch/arm/arm32/lib/findbit.S
+++ b/xen/arch/arm/arm32/lib/findbit.S
@@ -42,8 +42,8 @@ ENDPROC(_find_first_zero_bit_le)
* Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
*/
ENTRY(_find_next_zero_bit_le)
- teq r1, #0
- beq 3b
+ cmp r1, r2
+ bls 3b
ands ip, r2, #7
beq 1b @ If new byte, goto old routine
ARM( ldrb r3, [r0, r2, lsr #3] )
@@ -83,8 +83,8 @@ ENDPROC(_find_first_bit_le)
* Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
*/
ENTRY(_find_next_bit_le)
- teq r1, #0
- beq 3b
+ cmp r1, r2
+ bls 3b
ands ip, r2, #7
beq 1b @ If new byte, goto old routine
ARM( ldrb r3, [r0, r2, lsr #3] )
@@ -117,8 +117,8 @@ ENTRY(_find_first_zero_bit_be)
ENDPROC(_find_first_zero_bit_be)
ENTRY(_find_next_zero_bit_be)
- teq r1, #0
- beq 3b
+ cmp r1, r2
+ bls 3b
ands ip, r2, #7
beq 1b @ If new byte, goto old routine
eor r3, r2, #0x18 @ big endian byte ordering
@@ -151,8 +151,8 @@ ENTRY(_find_first_bit_be)
ENDPROC(_find_first_bit_be)
ENTRY(_find_next_bit_be)
- teq r1, #0
- beq 3b
+ cmp r1, r2
+ bls 3b
ands ip, r2, #7
beq 1b @ If new byte, goto old routine
eor r3, r2, #0x18 @ big endian byte ordering
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -358,7 +358,7 @@ static always_inline unsigned int __scan
const unsigned long *a__ = (addr); \
unsigned int s__ = (size); \
unsigned int o__ = (off); \
- if ( __builtin_constant_p(size) && !s__ ) \
+ if ( o__ >= s__ ) \
r__ = s__; \
else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG ) \
r__ = o__ + __scanbit(*(const unsigned long *)(a__) >> o__, s__); \
@@ -390,7 +390,7 @@ static always_inline unsigned int __scan
const unsigned long *a__ = (addr); \
unsigned int s__ = (size); \
unsigned int o__ = (off); \
- if ( __builtin_constant_p(size) && !s__ ) \
+ if ( o__ >= s__ ) \
r__ = s__; \
else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG ) \
r__ = o__ + __scanbit(~*(const unsigned long *)(a__) >> o__, s__); \
[-- Attachment #4: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-12-11 12:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-11 12:05 [Xen-devel] Xen Security Advisory 307 v3 (CVE-2019-19581, CVE-2019-19582) - find_next_bit() issues Xen.org security team
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).