Pixel vs. Android security bulletin

Fun fact!
Alongside of the Android Security bulletins are the Pixel Security bulletins. By the name one may assume that they are Google Pixel specific, but in reality they are just additional recommended security fixes.
These are by default only included in the monthly updates of the latest version of Android, and vendors aren’t required to pull them in to claim the month’s security patch level as that only covers the mandatory patches. This applies to aftermarket systems too!

Assuming that such aren’t pulled in, Android 10, 11 and 12 are currently 29, 15, and 6 months behind the PSB respectively.



Are you sure? Monthly updates are for Android 11, 12 and 13 (probably older as well). Are you now saying that older Android versions don’t get proper updates? That is really not the case. Citation needed :slight_smile:

For the record:

The Pixel Update Bulletin contains details of security vulnerabilities and functional improvements affecting supported Pixel devices (Google devices).

Pixels also have next Android features (Android 14), so it makes sense they differ, they run different code, even different than other Android 13 devices. That doesn’t mean older Android releases don’t get all updates. They just don’t have that vulnerable code.

Monthly updates for older branches are only the ASB.
Only the latest version of Android receives both the ASB and PSB.

You can look at the contents of any PSB, pick any single linked CVE, and clearly see it is in common AOSP code, not Pixel specific.

Pixel updates are for Pixel devices. It clearly states it. They do not apply to the generic Android updates, which are just as well maintained.

This is wrong. Do not let the Pixel in the PSB deceive you, please look at the actual PSB contents like I said.
They are not Pixel specific.

edit: here
For December 2022 PSB, in the framework+system section:

  • CVE-2022-20504 is a bug in screensavers
  • CVE-2022-20524 is a bug in vibrator hal
  • CVE-2022-20553 is a bug with logcat
  • CVE-2022-20554 is a bug with input handling
  • CVE-2022-20513 is a bug with ClearKey DRM
  • CVE-2022-20523 is a bug with incfs
  • CVE-2022-20530 is a misleading user-facing string
  • CVE-2022-20538 is a bug with sms package handling?
  • CVE-2022-20559 is a bug with package permission handling
  • CVE-2022-20543 is a bug with animations
  • CVE-2022-20526 is a bug with GPU debug metrics
  • CVE-2022-20528 is a bug with H265
  • CVE-2022-42544 is a bug with Wi-Fi network listing
  • CVE-2022-20503, CVE-2022-20506, CVE-2022-20508, CVE-2022-20519, CVE-2022-20522, CVE-2022-20533, CVE-2022-20537, CVE-2022-20556 various bugs with guest mode users being able to edit Wi-Fi settings and viewing passwords
  • CVE-2022-20505 is a bug with call log handling
  • CVE-2022-20509, CVE-2022-20557 bugs in FMQ
  • CVE-2022-20520 prevent overlays over the SimToolKit
  • CVE-2022-20525 bug with visual voice mail
  • CVE-2022-20529 bug with wrongly allowing wifi dialog on lock sceren
  • CVE-2022-20536 prevent user apps from sending broadcasts RCS unless permission granted
  • CVE-2022-20539, CVE-2022-20546 bugs in audio hal for audio equalizer?
  • CVE-2022-20540 bug in the window renderer
  • CVE-2022-20544 bug that wrongly re-enables disabled apps when clearing data
  • CVE-2022-20547 bug with Bluetooth permission checks
  • CVE-2022-20549 bug with keymaster data handling
  • CVE-2022-20550 bug that let screensaver invoke arbitrary activity with potentially elevated privileges

I can keep going, they aren’t Pixel specific

1 Like

Is it really that clear cut? Like I already said, the Pixel devices are running a mix of current and future release. They are not the regular Android release. Having different software, means different bugs and vulnerabilities. It would make no sense to prioritize Pixels and leave the rest open to security issues. If that was the case, then there must be a statement about this. Or a security researcher or community would be taking and complaining about. I think you assume this is the case based on these changelogs and software names. I don’t share that assumption. But if you have better proof, I can change my mind of course.

It’s right at the bottom of that page:

  1. Why are security vulnerabilities split between this bulletin and the Android Security Bulletins?

Security vulnerabilities that are documented in the Android Security Bulletins are required to declare the latest security patch level on Android devices. Additional security vulnerabilities, such as those documented in this bulletin are not required for declaring a security patch level.

1 Like

The only Pixel specific parts of the PSB is the Pixel section, and even then those issues can impact other Samsung or Qualcomm devices depending on which Pixel they apply to.

The System, Framework, Media, and Kernel sections apply to all other devices too, but Google can barely get vendors to provide monthly ASB updates on time, how would vendors manage if each one was doubled in size?
Not to mention Google doesn’t want to have to check/backport/test/review those to older versions.

1 Like

This is not really how software works. It’s not a top down structure. It could affect it. But it’s unclear from what I can tell. A Pixel may contain code of Android 14, thus Media Framework X, while Android 11 has version B, which doesn’t implement codec Y that has the out of bounds vulnerability. Just an example that it isn’t that clear cut. It may be though. But if it’s not explicitly noted then I have some reasonable doubts.

Pixels are one of the most secure devices. But it would not make sense to prioritize your own devices, if you don’t want to upset your partners that you depend on.

Citation needed.

This is not really how software works. It’s not a top down structure. It could affect it. But it’s unclear from what I can tell. A Pixel may contain code of Android 14, thus Media Framework X, while Android 11 has version B, which doesn’t implement codec Y that has the out of bounds vulnerability

This is wrong again.
How do others and myself manage to backport security fixes from the latest bulletins all the way back to Android 7 then? Patch Counts - DivestOS Mobile

That “Pixel lockscreen bypass” last month, was NOT Pixel specific and Google only mentioned it affecting Android 10, despite impacting Android 7. They only note 10, because that is the oldest branch they support.

I don’t know why you are arguing that these security issues don’t impact others, when they clearly do.
I’m not singling out anyone here either, most vendors fall behind or completely ignores these.

Any system right now, Pixel or not, that has TQ1A has all of those system+media+framework security patches listed in the December 2022 ASB and PSB.

sorry @yvmuell for going so offtopic of that thread

1 Like

I opened a seperate topic for this discussion.

@SkewedZeppelin no problem at all for me, just thought its better done seperately to not confuse the “normal” user too much😉


They are not holding them back, they are simply only available in the latest maintained branch (currently android-13.0.0_r16).

see Pixel vs. Android security bulletin - #5 by SkewedZeppelin

They run different software than other Android 13 device

Every single one of the linked issues in the PSB is either in AOSP or the Linux kernel, not whatever proprietary branch they may be shipping on actual Pixels.

Even ignoring that they may or may not impact older branches, any vendor shipping the latest version but not the latest monthly branch would still be impacted by the majority of the issues in the PSB.

1 Like

I replied to that and explained why that isn’t a good example.

Maybe we’re just not understanding each other.

No, I understand. You want a clear paragraph on source.android.com that describes this practice.
I do too, but it doesn’t exist.

Here is GrapheneOS describing this practice too if it helps:


Android 7 is end of life, no need to mention it. But if it mentioned Android 10, then yes, not Pixel specific.

I’m just skeptical. For work I am involved with security as well. Not every software version is affected by the same bugs, sometimes it’s just in one major version or even a minor version with feature X enabled or module Y loaded. That’s why I find it hard to believe that Google fixes bugs for their Pixel and not include them for other Android versions. Unless of course they are on a different branch. Then the patch doesn’t apply. Otherwise there is no reason to not include it.

It could be though, not saying it’s impossible for Google to make their own devices better than others. But just listing CVEs that are included for Pixels is not the proof that convinces me. They run different software than other Android 13 devices. And different than Android 11. That they run the same software by name doesn’t mean they run the same version.

Anyway, if you have concrete proof I would like to read it. But this seems like an educated guess. Which again, may be true. But is not convincing for me.

Graphene is a knowledgeable source. So I guess I’m wrong then. That makes it quite a mess. Android is known for that though. But this adds even more confusion to it.

Would’ve been cool if they used overviews like this below. Less open for interpretation. Clearly stating what the problem is, which package of that release and if it’s affected. RHEL does that quite well.


Ultimately patching CVEs is bad. Vendors should simply be shipping whatever the latest monthly version of Android is available, instead of putting duct-tape on swiss cheese.

Unrelated: Here are a thousand unpatched potential security issues in Linux: https://syzkaller.appspot.com/upstream

1 Like

Before merged, issues need to be reported, fixed and tested. That makes sense. It would be different if one LTS kernel doesn’t get certain fixes while the latest one does. While the critical issue affects both. For both a fix should be released when ready. Linux doesn’t do time based releases though. And even if it’s an old LTS, it usually then only gets security updates. So still maintained in that sense.

But we digress a bit. Thanks for sharing this info. Still have to check what it actually means on version levels. Some security issues are not affecting older releases and the other way around. So it still sounds odd that anything a Pixel gets fixed also applies to an Android 11 device.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.