Hi,
I had a look at CVE-2018-19665 regarding qemu in oldstable/stable.
summary: the bluetooth subsystem uses signed length variables at multiple
places. These length variables are used, among others, in memcpy calls. A
malicious guest VM could attempt to crash the host by passing negative len
values (in fact, huge len values interpreted as negative numbers) to these
functions.
The suggested patch[0] changes the type of these length variables to size_t
(unsigned) and adds a few assert calls to make sure the code is also
resilient again large values of len.
First, it is not completely clear to me to what extent this length variable
is under the control of guest VM users.
say, if guest kernel drivers process calls first, then these large/negative
values are likely to be rejected before they have even reached the affected
qemu code. Under this hypothesis, guest VM users would need to have full
control over the guest kernel to exploit this vulnerability (making exploit
more difficult in real envs ?).
I might be wrong on this point due to my limited knowledge of this
code-base.
Anyways, given that the patch is quite large (though straightforward), that
the subsystem doesn't seem to be very actively maintained and that the user
base is quite small, it is maybe better to mark this no-dsa in stretch and
jessie.
Cheers,
Hugo
[0] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03570.html
--
Hugo Lefeuvre (hle) | www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
Attachment:
signature.asc
Description: PGP signature