Hi everyone. LTS Kernel 4.9 was EOLed in the first week of January. I was curious to understand how this affects security since the device should continue to receive monthly Android security patches. Do the monthly patches address all the kernel vulnerabilities if any?
Thanks.
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
tl;dr: if in doubt, watch your devices kernel source repository
the android security bulletins have 2 “patch level dates”, one for framework, one for kernel and firmware.
In general, Lineage and /e/ releases for devices outside their manufacturer support mostly have the framework patches, not necessarily kernel (for EoL kernels) and firmware. A subsequent patch level doesn’t mean they covered the last months kernel/firmware.
If the manufacturer isn’t issuing updates anymore, it’s up to the individual maintainers to do kernel backports.
Answer is pretty device and maintainer specific. I think most older devices have the kernel that last saw a GPL release and nothing in between.
There’s an autopatcher by DivestOS that backports what has an CVE. Alot of issues don’t get an CVE assigned though (but very public / critical ones do). A soft guideline by Lineage for maintainers and kernel problems is “if the issue breaks the news or has its own logo, pls patch”).
Newer device having seen their market release with Android 11 and 12 have GKI kernels that are a lot easier for maintainers to keep updated.
Thanks for clearing it up. I didn’t understand all of it but enough I think to satisfy my curiosity. I plan to use my F1 for another few months as my daily driver so I was kinda worried about the security implications. A kernel upgrade might be possible. More than 2 years ago there was some work to bringup the then mainline Linux kernel 5.x to F1…
the android kernel for your device has keen maintainers, so I’m sure for critical security issues you’ll see backports - GitHub - LineageOS/android_kernel_xiaomi_sdm845 … it’s possible that they move kernels too. But beware that only the lineage-20 branch can see attention as the device already moved releases.
sdm845 is a SoC with probably the best kernel mainline support currently. You can boot successfully into AOSP mainline - but miss camera, modem, sensors and leds. I’m sure this will improve, so hold onto that device.
There is only one patch level, I explain it here: Patch Levels - DivestOS Mobile
Also for example, here are all the dozens of security patches I add to beryllium (on top of the latest Lineage sources): Scripts/LineageOS-20.0/CVE_Patchers/android_kernel_xiaomi_sdm845.sh · master · DivestOS Mobile / DivestOS-Build · GitLab
Yes. I will be using F1 as a secondary device for years to come as I believe it’s performance would be still adequate. I still have 6+ years old Redmi Note 3 and 3s which currently serve as secondary devices. The latter got a huge boost following a kernel upgrade from the official 3.18 to 4.9 ported over from SD625. For F1 there was a post in a TG group about someone working to bringup 4.14 kernel but no news ever since.
While GKI should make custom ROM development easier it seems that on the whole it’s actually going down a bit which is unfortunate.
Much clearer now. Thanks.
I had read about DivestOS earlier in an XDA article IIRC but somehow I had forgotten about it. I will have to look into later as I can’t switch ROMs now.
I’m irritated you insist on there being “only one patch level”. Sure, “on paper” - for users that don’t have EoL’ed devices or especially Pixels, true! - but that is a subset of devices - for aftermarket devices I’d be impossible to adhere to e.g. the SoC fixes assigned to a patchlevel, they necessarily miss them in subsequent “patch levels”.
At Lineage, you’ll see the framework patches in the weekly builds or what /e/ puts out there monthly - but not necessarily vendor and kernel being applied. You might remember that thread about kernel maintainership:
So when you read in the about pages that the device is up to patch level 2023-01-01, it doesn’t follow it ever received 2022-12-05 or any of the SoC, vendor or kernel patches. We both know it’s just a string definition in a Makefile, there’s no way to verify what ASBs were honored in the build.
There’s an app called Snoop Snitch that verifies whether all the claimed security patches are actually applied or not.
I stand corrected, looks pretty cool ! - Mind the Gap: Uncovering the Android Patch Gap Through Binary-Only Patch Level Analysis « HITBSecConf2018 – Amsterdam (2018)
[…] users have to blindly trust their phone vendors to install patches. We find that this trust is not warranted for many Android vendors, most of which skip at least some patches. […], we find missing Android patches on phones or from firmware files. The analysis compares function signatures to large collections of pre-compiled samples.