Android CVEs: How Patch Levels and Vendors Change Exposure

Introduction

The objective behind generating a Software Bill of Material (SBOM) for the firmware you build, integrate, or deploy is not only to know which software component and version are present, but to map those component versions to known vulnerabilities.

Traditionally, this mapping between a component and its version to a given set of publicly known vulnerabilities has been done with the Common Platform Enumeration (CPE). The CPE is a string that explicitly defines affected components with the following format: cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>. CPEs are themselves attached to CVEs.

For vulnerabilities that may be documented but not in the official CVE database, PURLs are used with the following standardized format: scheme:type/namespace/name@version?qualifiers#subpath.

This mechanism works well but has two major limitations:

1. Correctness. The CVE Numbering Authority (CNA) assigns the right CPEs and maintain the set of CPEs for the CVEs it has published over time.
2. Expressivity. A CPE does not provide sufficient information about the specific conditions required for a CVE to be reachable and exploitable. This includes affected module, function, feature, etc.

In this second blog post on CVE matching, we'll explore those two limitations by exploring the Android OS CVEs.

The version-only CPE Problem

Whenever Google publishes a CVE affecting Android OS, they attach CPEs that only express affected systems up to the Android OS version (e.g. cpe:2.3:o:google:android:10). Publication of those CVEs usually happens on the same day they release Android patch levels fixing those CVEs.

These patches are documented as part of Android Security Bulletins, where tables detail which CVE has been patched on which AOSP version as part of which patch level. In the screenshot below, we can see for example that CVE-2024-0032 is fixed on 12, 12L, 13, 14 if you applied the 2025-03-01 patch level.

This means that by the time Android OS CVEs are released, their CPE information is already outdated and invalid.

Keeping our examples above, if your firmware currently runs on Android 12 with patch level 2025-03-01, a CPE match will consider that CVE-2024-0032 is affecting you while in fact it’s not.

An Android CPE often identifies google:android and an OS version. That is enough to discover plausible CVEs, but Android’s remediation contract is expressed through monthly security patch levels. Two devices reporting Android 13 can therefore have very different exposure depending on whether their patch level predates or follows the bulletin that addresses a CVE.

Patch level is part of the version semantics

To explore how significant this patch level gap is, we collected all CVEs with at least one CPE for google:android. Out of 6,512 CVEs, 4,847 distinct CVEs are present in Android Security Bulletins.

We collected every explicit Android OS label from 4.4.4 through 17. Equivalent spellings such as "16 QPR2" and "16-qpr2" normalize to one label; point releases and 12L remain distinct. That produces 21 explicit version labels for analysis. A further 2,876 bulletin CVEs lack a usable explicit version label and remain visible in overall coverage accounting. Exactly 2 CVEs carry the label 6.1 in a Linux-kernel section of a bulletin; the trace preserves that evidence, but the label is excluded from Android OS bars.

Note: “raw candidate” does not mean danger and “removed” does not automatically mean a historically erroneous NVD record. The first is a version-based discovery result. The second is an assessment refinement made with explicit patch-level evidence.

For each OS label, “latest patched” means the newest patch level explicitly available for that OS in the pinned bulletin data. For an end-of-life release, that is its final attainable level, not today’s calendar month.

The contextual decision uses our internal “Android AOSP Rule” semantics. If the tested OS version is at or after a version explicitly named by the bulletin and its patch level is at or after the bulletin patch date, the rule weighs against impact. If either requirement is not satisfied, the candidate remains. When version evidence is unavailable, the patch date decides conservatively. A raw candidate without a bulletin rule remains a candidate and is counted as insufficient patch-level evidence.

For Android 4.4.4 at its final attainable patch level, 893 version-only candidates enter the comparison and 253 remain, a 71.7% candidate reduction. For Android 16 at the pinned latest patch level, the corresponding counts are 206 and 19, a 90.8% reduction.

Note that these bars are not a support-lifecycle comparison. Older releases have fewer attainable bulletin dates, and the corpus changes over time.

Coverage explains what the reduction cannot

Since metadata about whether an Android OS CVE affects a given version and patch level is coming from Android Security Bulletins, a good metric is the bulletin coverage by version. This way we can spot potential gaps in our information collection.

The coverage chart below splits each raw per version population into candidates with a usable bulletin rule and candidates without sufficient patch-level evidence. It is possible for coverage to be high while reduction is low: a bulletin can explicitly say that the tested version or patch level is still affected. Conversely, missing coverage never licenses removal.

There is a visible dip between version 8.x and 12 included. Our initial assumption was that it was driven by vendor specific CVEs, without knowing exactly which vendor was causing that. Keep on reading to find the culprit.

Vendor context overlaps the OS story

Even though they’re all linked to google:android CPE, Android CVEs do not all apply uniformly across devices. A fair share of these CVEs only affects custom code from manufacturers such as Qualcomm, Samsung, Mediatek, or LG.

That information is visible from both the CVE description and references, usually linking to vendor specific resources.

A good example of such cases is CVE-2024-34663, which reports on libquram - an image decoding library that’s unique to Samsung devices - and link it to google:android CPEs:

The source of these “bad” CPEs are the vendors, and in this specific case the “Samsung Mobile (Mobile Communications Business of Samsung Electronics Co., Ltd.)” CNA. We consider them wrong because they consider that any Android device running Android version 12, 13, or 14 is affected by a bug that is unique to Samsung devices. And even within Samsung devices, not all of them embed libquam.

By plotting the distribution of vendor specific CVEs, we found that 21% of Android OS CVEs are vendor-specific CVEs:

The plotted categories contain 387 Qualcomm, 533 Samsung, 63 MediaTek, and 46 LG CVEs. CVEs with more than one recognized vendor signal are counted once in the multi-vendor category; CVEs without one of these singleton signals remain in “other Android CVEs.”.

To test whether the lower bulletin-rule coverage from Android 8.x through 12 co-occurs with more vendor-specific CVEs, we partitioned each version’s raw NVD population using the same deduplicated vendor categories as the catalog-level view. We can already see the increasing prevalence of Samsung within vendors between Android 7.0 and 12 included.

The aggregate distribution alone does not establish a driver, so we joined vendor category and bulletin-rule coverage on canonical CVE identity within each tested version.

The join shows that Samsung is the primary composition driver of the lower aggregate coverage from Android 8.x through 12. None of the Samsung-tagged candidates are covered by a bulletin rule in Android 8.0, 8.1, 9, or 12; only 1 of 305 is covered for Android 10 and 1 of 249 for Android 11. Qualcomm coverage stays between 97.2% and 97.8% over the same releases, which supports the hypothesis that Qualcomm CVEs are usually represented in Android bulletin patch rules.

Samsung-tagged candidates account for between 64.8% and 92.9% of candidates lacking bulletin-rule evidence in that interval. The deterministic counterfactual in the plot removes only those rows from each version’s denominator: coverage rises from 69.5% to 86.6% for Android 10 and from 81.9% to 98.4% for Android 12, with the same direction for every release from 8.0 through 12.

Application names are identities, not labels to count twice

With the CVEs that do affect a given Android OS version and patch level, they may still not impact you if they’re affecting specific AOSP applications that you’re not embedding in your firmware.

These could probably be expressed as <target_sw> CPE field, or through custom PURLs for Android application packages (e.g. pkg:aosp/com.google.android.nfc@1.0) instead of wildcard for the whole OS.

We have some application-specific rules for Android OS covering some but not all application-specific CVEs. They can be seen below:

The comparison population includes 92 Bluetooth, 30 NFC, 21 Settings, 20 Telephony, 4 Keymaster, and 3 Wi-Fi CVEs. “Other application-specific” preserves package-scoped findings outside those named groups; “non-application-specific” contains CVEs with no application rule.

Key Takeaways

Performing naive CVE matching using Android OS version only is insufficient and will result in a vast amounts of false positives being reported.

At ONEKEY, we address this by making sure that:

• the CVE affects the version and security patch level your firmware is currently running, reducing CVEs by 90% on Android 16
• your firmware is manufactured by that specific vendor or running on that specific manufacturer chipset when a CVE is linked to a vendor
• your firmware embeds that Android application if the CVE affects a specific Android package

These are things we have to perform ourselves due to the low quality of CPE information provided by Google and vendors. In an ideal world, the Android team would maintain CPEs linked to Android CVEs by always providing the security patch level as part of the "update" field of CPEs, providing the package name in "target_sw" when it affects an AOSP package, and disputing or fixing data from vendor-specific entries published by major vendors such as Samsung or LG.

In the meantime, you can be assured that our platform cuts through the noise for you so you can focus on what's actually affecting your Android firmware and devices.