Bug 1117749 - (CVE-2018-19665) VUL-0: CVE-2018-19665: kvm,qemu: Integer overflow in Bluetooth routines allows memory corruption
(CVE-2018-19665)
VUL-0: CVE-2018-19665: kvm,qemu: Integer overflow in Bluetooth routines allow...
Status: RESOLVED WONTFIX
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/219879/
CVSSv3:RedHat:CVE-2018-19665:6.4:(AV...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-11-29 09:32 UTC by Robert Frohl
Modified: 2021-08-18 13:40 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Frohl 2018-11-29 09:32:28 UTC
rh#1607652

An integer overflow resulting in memory corruption issue was found in various Bluetooth functions. It could occur in routines wherein 'len' parameter is a 'signed int' which subsequently converts to an unsigned integer resulting in memcpy() copying large amounts of memory.

A user inside guest could use this flaw to crash the Qemu process resulting in DoS.

Upstream patch:
---------------
  -> https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03746.html

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1607652
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-19665
Comment 1 Robert Frohl 2018-11-29 10:17:58 UTC
My investigation suggests that all codesteams are affected for kvm and qemu.
Comment 2 Bruce Rogers 2019-01-10 18:01:26 UTC
Upstream has disputed this this fix. I still need to look into what the follow up should be.
Comment 3 Bruce Rogers 2019-01-28 21:59:45 UTC
The v3.1 qemu release had the whole Bluetooth subsystem marked deprecated, with the corresponding commit id stating: "It has been unmaintained since years, and there were only trivial or tree-wide changes to the related files since many years, so the code is likely very bitrotten and broken." and "Since we are not aware of anybody using bluetooth with the current version of QEMU, let's mark the subsystem as deprecated"

It is also my experience that it is ususable. Given that, the above info, and the fact that the fix identified here was not accepted (nor anything like it), I feel we should not attempt to apply this patch.
Comment 4 Bruce Rogers 2019-01-28 22:00:38 UTC
(In reply to Bruce Rogers from comment #3)
> The v3.1 qemu release had the whole Bluetooth subsystem marked deprecated,
> with the corresponding commit id stating: "It has been unmaintained since
> years, and there were only trivial or tree-wide changes to the related files
> since many years, so the code is likely very bitrotten and broken." and
> "Since we are not aware of anybody using bluetooth with the current version
> of QEMU, let's mark the subsystem as deprecated"
> 
> It is also my experience that it is ususable. Given that, the above info,
> and the fact that the fix identified here was not accepted (nor anything
> like it), I feel we should not attempt to apply this patch.

I meant to reference the commit mentioned. It's c0188e69d.
Comment 6 Gianluca Gabrielli 2021-05-21 12:35:55 UTC
Hi Bruce,

I dug into it a little bit more, as you said the Bluetooth stack was marked as deprecated with version v3.1.0-rc1 (c0188e69d [0]) and actually removed with version 5.0.0-rc0 (1d4ffe8 [1]).

According to that the following packages should be affected:

 - SUSE:SLE-11:Update/qemu         0.10.1
 - SUSE:SLE-12:Update/qemu         2.0.2
 - SUSE:SLE-12-SP2:Update/qemu     2.6.2
 - SUSE:SLE-12-SP3:Update/qemu     2.9.1
 - SUSE:SLE-12-SP4:Update/qemu     2.11.2
 - SUSE:SLE-15:Update/qemu         2.11.2
 - SUSE:SLE-15-SP2:Update/qemu     4.2.1

 - SUSE:SLE-11-SP1:Update/kvm      (qemu 0.12.5)
 - SUSE:SLE-11-SP3:Update/kvm      (qemu 1.4.2)
 - SUSE:SLE-11-SP4:Update/kvm      (qemu 1.4.2)

While the following are not affected:

 - SUSE:SLE-15-SP3:Update/qemu     5.2.0
 - openSUSE:Factory/qemu           6.0.0

As you pointed Charles had backported this patch [2] to the embedded qemu in xen.
If you think it is doable for you to take his work and apply it to the above-mentioned affected packages, please proceed. Otherwise, I can flag these packages as WONTFIX in our vulnerability tracker and this issue won't show up again in the future.

Thanks for your input. 

[0] https://github.com/qemu/qemu/commit/c0188e69d336b5c921e026b3307e70b6ea7e9a47
[1] https://github.com/qemu/qemu/commit/1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3
[2] https://bugzilla.suse.com/show_bug.cgi?id=1117756
Comment 7 José Ricardo Ziviani 2021-07-26 14:47:57 UTC
Hello Gianluca,

I'm not convinced this patch worth applying. The reason is based on Paolo's comment: 

-----
You are not fixing anything here; if the length was negative before, it
would still overflow and it would now be a huge positive value.

So you have to first find out all places where something is subtracted
from the length, and ensure it's okay or add assertions.

Then you have to check a much more important issue: places that use a
fixed-size buffer such as vhci_host_send should range check len first,
again with an assertion if needed.

Only then it makes sense to use size_t.
-----

So applying it will mark the bug solved, but it won't be fixed at all, giving us a false sense of security. If you don't mind, I prefer to have it "won't fix".

What do you think?

Thank you
Comment 8 Gianluca Gabrielli 2021-08-18 13:40:56 UTC
Hi José,

I'm fine with that, thanks for your input.