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
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.
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
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.
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.
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.
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.
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
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.
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.
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.
