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
signature.asc
Description: PGP signature
