Critical Bluetooth Vulnerability in Android (CVE-2020-0022) – BlueFrag

On November 3rd, 2019, we have reported a critical vulnerability affecting the Android Bluetooth subsystem. This vulnerability has been assigned CVE-2020-0022 and was now patched in the latest security patch from February 2020. The security impact is as follows:

  • On Android 8.0 to 9.0, a remote attacker within proximity can silently execute arbitrary code with the privileges of the Bluetooth daemon as long as Bluetooth is enabled. No user interaction is required and only the Bluetooth MAC address of the target devices has to be known. For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address. This vulnerability can lead to theft of personal data and could potentially be used to spread malware (Short-Distance Worm).
  • On Android 10, this vulnerability is not exploitable for technical reasons and only results in a crash of the Bluetooth daemon.
  • Android versions even older than 8.0 might also be affected but we have not evaluated the impact.

Users are strongly advised to install the latest available security patch from February 2020. If you have no patch available yet or your device is not supported anymore, you can try to mitigate the impact by some generic behavior rules:

  • Only enable Bluetooth if strictly necessary. Keep in mind that most Bluetooth enabled headphones also support wired analog audio.
  • Keep your device non-discoverable. Most are only discoverable if you enter the Bluetooth scanning menu. Nevertheless, some older phones might be discoverable permanently.

As soon as we are confident that patches have reached the end users, we will publish a technical report on this vulnerability including a description of the exploit as well as Proof of Concept code.



    1. Linux systems usually use Bluez, what is a different project than the Android Bluetooth stack. We have applied the same fuzzing technique against an Ubuntu system and could not observe any crashes.

      1. Bluetooth works in Linux just fine, pretty much on par with MacOS and far better than in Windows. Sounds more like confusing operator’s incompetence with an OS problem to me.

      2. Sarcasm doesn’t run well in most Linux geeks but I’m fairly sure Linus is working in that.

  1. “As soon as we are confident that patches have reached the end users, we will publish a technical report on this vulnerability including a description of the exploit as well as Proof of Concept code.”

    Given the generally terrible rate of patching on android handsets what criteria will you use to judge that ‘patches have reached end users’.

    1. That most major Vendors (Samsung, Huawei, Xiaomi) have distributed a patch plus a couple of days for the users to react, what should take approx 2-3 Weeks in total. Therefore even after the 90+14 days used by Google Project Zero [1]

      Note that as the patch was now published, the exploit can be reproduced as well. We needed three weeks for this and there are far more competent people out there.


    1. During my thesis at SEEMOO we have implemented our own fuzzer for the Broadcom Bluetooth firmware. In this case we used a modified firmware and have broken Android instead of the firmware by accident 簪\_()_/簪

      1. Are you going to opensource it? I’d love to take a look at this specific-case fuzzer.

  2. hi Ruge, im an digital journalism for, can i know, what is Bluetooth daemon or BluetoothD definition? based on Google, i didn’t find the answer… please answer my question thanks

    1. Hi, the Bluetooth daemon is a process on the Android system that runs in the background (daemon) that is responsible for managing the Bluetooth controller and handling of various Bluetooth related protocols, such as HCI, L2CAP and GATT. As it has to process attacker-controlled input it is susceptible to attacks. In addition, it has to run with high privileges (not as ‘root’ like on Linux) to support features like:
      – file transfer => read files
      – share Internet connection => configure network and VPN
      – Human Interaction Devices => emulate keyboard and mouse

  3. Ruge,

    To pinpoint the vulnerability, it looks like the single line code change that fixes the problem, is this one?

    line 224

    – packet->len = partial_packet->len – partial_packet->offset;
    + packet->len =
    + (partial_packet->len – partial_packet->offset) + packet->offset;

    GAP: Correct the continuous pkt length in l2cap

    L2cap continuous pkt length wrongly calculated in
    reassembly logic when remote sends more data
    than expected.

    Wrong pkt length leading to memory corruption

    Hence the Correct the continuous pkt length in
    l2cap reassembly logic.

    Bug: 135239489
    Bug: 143894715
    CRs-Fixed: 2434229
    Test: make and internal testing
    Change-Id: I758d9e31465b99e436b9b1841320000f08186c97
    Merged-In: I758d9e31465b99e436b9b1841320000f08186c97
    (cherry picked from commit 337bd4579453bd6bf98ff519de3ac1019cd30d28)
    (cherry picked from commit 602f4b44fe30ec8b225e1cee5f96817607d93e5a)

    And if so, it looks like this flaw had been present in the code for at least the last 5 years

    1. Yes, this is the fix for the vulnerability. But as you can see from the bulletin, this bug is not exploitable on all Android versions and there is a reason for that. But I’m sorry, no spoilers yet

      1. Do you think you’re the first group to find this? This is a pretty serious vulnerability. Especially for devices with sequential NIC MAC IDs

      2. We are for sure not the first ones who found this bug. After we have tracked down and understood our crashes we realized, that the bug was already fixed in the master branch by the commit Ben Siron has referenced. The commit was publicly visible at that time but was not applied to any release for some reason. It is hard to blame anyone for this as the severity is not really visible in the code. We were probably the first ones to realize, that this bug is exploitable because we found it in a different way.

  4. I did a bit of searching to see what permissions the Bluetooth process has, since if an attacker is allowed to execute code running as this process, this would define what a potential attacker is able to do.

    This is what I found for the current version of the Bluetooth app:


    Some of these permissions (while not root level access) are fairly powerful. Definitely not the kinds of things I would want to allow an attacker to do on my phone. And definitely not the kinds of things that I would want to see many phones doing simultaneously due to a wormable infection.

    Allows low-level access to power management

    Allows access to the list of accounts in the Accounts Service.

    Allows an application to call APIs that allow it to query and manage users on the device. Allows apps to manage users on the device, including query, creation and deletion. This permission is not available to third party applications. On Android, most apps/packages run under their own separate ‘user’ account, identified by a userId / UID / appId / AID. Therefore, this privilege allows management of other packages / applications.

    Allows an application to read, send, or modify SMS messages. Malicious apps may delete your messages.

    Allows an application to read, write the user’s call log data.

    allows querying for all running tasks on the system

    Allows using PowerManager WakeLocks to keep processor from sleeping or screen from dimming.

    Allows an application to call any phone number, including emergency numbers, without going through the Dialer user interface for the user to confirm the call being placed.

    Hopefully android phone manufacturers will issue security updates to include this fix, but the track record so far is not encouraging. I’m turning off android bluetooth for the meantime.

  5. Like, most people won’t ever see any patches from their Vendors. It just wont happen. No body cares. My V30+ from M1 or some other operator has the patches from May 2019. And nothing I could do.

    1. This is definitely a problem. I saw a great discussion on this topic [1] at the weekend. Sadly, besides flashing a custom ROM, there is not much more you can do. Hopefully customer complains will change the situation some day. .As far I can see the V30 is still sold?!


      P.S. This work was done on a perfectly fine laptop from 2013

  6. Do you and the attacker need to be on the same internet connection or is this just strictly Bluetooth connection?

    1. For convenience we choose a reverse-shell over network, so you can connect back to any server on the internet. It should also be possible to bring the daemon back to an operational state and create a reverse shell over Bluetooth.

  7. Hello, we are the OEM of the automobiles. We have products in the range of affected Android version but we are unclear if out product is actually affected. Is there a way to get a copy of poc so we can start verify and fix this vulnerability before the poc release to the public? Thanks

  8. Has anyone checked to see if any versions of Android Auto are vulnerable to this? Cars aren’t updated as often or as cleanly as tablets/phones/etc.. and I think most people use that Bluetooth interface for hands-free which means they’d be enabled and active on a lot of vehicles. Wondering as I’m trying to get a copy of the firmware for my vehicle.

    1. From my point of view, the tablet/phone patch process is already horrific. Do you have more information or references on that?

  9. Can you provide a method for testing this vuln? I am trying to verify it across my devices, but I am not able to reproduce.

  10. In general, if you are running a Android device Android 9 and earlier and with a patch Level prior Feb 2020, you are probably vulnerable. We do not want to release PoC code to a limited set of people and keep the disclosure process transparent.

    1. Anyone recommend any good proof of concept code/scripts? I need to verify we fixed it in our older android build we are supporting.

    2. How does this problem relate to the heavily discussed Corona tracing apps, that are all based on BT? What you say above is, do not active BT without having installed patch level February 2020, but most phones will never see that (e.g. my phone, where Sony has stopped updates in Sep 2019). That limits the amount of Android phones, that safely can use the tracing apps (not talking about privacy issues here!) to maybe 10-15% (the phones that still get updates).

      1. First of all, luckily this Bug has been fixed before the Corona thing. We have verified the patch using the PoC and our fuzzer. We can not observe any more crashes. Therefore for updated devices, the risk is mitigated.

        Protocol interaction always comes with the risk of vulnerabilities. This does not only apply to Bluetooth but also WiFi, NFC, Baseband, web browsers, etc. Therefore having an outdated device comes always with a risk of compromise. The main problem here is the bad patching behavior of the vendors.

        If you do not receive any patches and want to stay secure in the long run, you might want to install an up to date custom ROM. Even though, this solution is not for everyone possible.

        I did not look into any corona tracking app in detail. We provided our PoC, so the people designing those apps can estimate the risk, which depends on the implementation. From a theoretical point of view, you do not need protocol interaction (e.g. active connection) as you are only interested in the presence of nearby devices. Theoretical this can be securely implemented with this vulnerability in mind, but I’m not sure of the current support of those features by the Operating System.

  11. On Android 8-9, there is a parameter for high accuracy location using Bluetooth even when Bluetooth is off. Should this be disabled also? Thanks in advance for advice.

  12. Well, you should be able to show the PiC its been past the accrued time you mentioned required before publishing…

    1. In order to be exploitable: No.

      In order to run the exploit: You have to create a raw HCI Bluetooth socket, so you ave to have elevated privileges. Normal apps can’t do this and. You have to be part of one of the Bluetooth groups or have to be root. After exploitation, the attacker inherits the rights of the daemon and therefore also required permissions to run the exploit that way.

  13. Hi, the your POC not work. I tried to reply with the python script with the of the target phone, i receive an error on line 352 “e= echo[:] type error: bool object ha no attribute….”

  14. Why this error?
    Traceback (most recent call last):
    File “”, line 83, in recv_l2cap
    File “/usr/lib/python2.7/”, line 173, in meth
    return getattr(self._sock,name)(*args)
    error: [Errno 111] Connection refused

    1. Hi,
      sorry for the late response. It looks like the target system does not accept connections, or like a typo in the target address. Do you run the PoC against an Android phone? Those should accept connections per default if the target address is correct. Can you run a normal l2ping against the target device?

  15. Explains why my previous two phones at times had bluetooth activate when i hadnt activate it. Went to a slightly newer phone in December with android 7. Was going fine until new years eve. At 22 past midnight bluetooth activated. Turned it off when i noticed as i went to take some photos. Later found out support for android 7 ended midnight 31 Dec. Kind off weird….

  16. China is the country that is so much popular in all the ways and its at&t bundles industries are so good. in my suggestion essay writing service reviews will make you more valuable and good in all the kinds to make you well.

  17. Weekly slim software is devised for the kjkinteriors proper running of the machines and all computers. The methods of the software have been designed for the uplifting of the huge things for the humans. This has been arranged for the full use of the parameters for the human in life.

Leave a Reply

Your email address will not be published. Required fields are marked *