1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. 
2. Over a year and a half ago, it was apparently fixed in the upstream kernel. 
3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. 
So you might read that and think "Ok, probably a rare mistake"...
4. This is apparently a _super_ common sequence of events, with kernel vulnerabilities getting lost in the shuffle, or otherwise not backported to "stable" kernels for a variety of reasons like the patch no cleanly longer applies.
Dmitry Vyukov (original author of syzkaller fuzzer that found this 2 years ago) gave a very interesting talk on how frequently this happens a couple weeks ago at the Linux Maintainer's Summit, along with some discussion of how to change kernel dev processes to try to dramatically improve things:
I'm amazed the GRSecurity people have managed to do it for so long. Even if merging their stuff mainline legitimately wasn't practical, I've seen plenty of snark and dismissiveness from the Linux team towards them and others. And GRSEC does actively bring in CVEs into their kernel patches all the time and get paid via sponsors to do so.
I'm sure going through old CVEs is a great way to find "zero days" and/or relapses after old patches. Or even just following the work GRSec does there's probably plenty of stuff for a highly motivated company like NSO to exploit.
Why even post this, when it has nothing to do the with the case GP & OP described? It's misleading at best.
The failure here is in the way Google has set its Android development process. They keep a separate "stable" kernel, and manually select certain patches to backport to. In process they skip all kinds of patches - performance, features, and yes, security ones. Given that only selected patches are backported, the process is best described as insecure by default. It was Google's decision to favor stable API over security here.
This is compounded by the fact other Android phone vendors are pretty slow at releasing OS upgrade - and tend to stop releasing them altogether shortly after the phone's no longer manufactured.
The mainline kernel, as released by the Linux core team is up to date with security. Hold to account people that decided to skip patches as a matter of course, resulting in the insecure by default process.
To me, the particulars of this exact case are not as interesting as the fact that the entire Linux patching and backporting of security issues seems _very_ fragile, with things frequently getting "lost" for mundane reasons, and a key part of the "why" it is so fragile is due to many of the core Linux development processes.
This particular CVE is apparently one small example that happened to catch some headlines out of _thousands_ of similar problems.
That talk linked above by Dmitry Vyukov is worthwhile for getting a sense of the magnitude of the problem.
Now why that fix never made it in most vendor kernels (besides a few like the one in the Pixel 3 that is based on 4.9) is a good question. But at the same time there is the reality, that everyone focusing on the upstream LTS kernel would have never gotten the fix.
I think it's still the won't layer. Google may be able to put some pressure to change things, but it's describe the issue as "the failure is in the way SOC manufacturers have set their kernel porting process". You often get chips which work with one version and a dump of specific drivers. Beyond pressuring the company to upstream their changes, or writing clean room versions, I don't see many solutions.
But isn't the issue that Android didn't merge it? Linux patched it.
Also AFAIK Blackberry only provided a hardened kernel with a single device in 2015 called Priv. I haven't heard anything from them since... maybe someone could correct me here.
Can you give some reference for that claim?
If you want more, literally google “baseband attack host processor memory” or “baseband exploits DMA” or “baseband exploits memory”.
This falls pretty much on Google and people in charge of the backports
Hence these issues, arguably.
The fact you use the word "prioritize security" is indeed telling. Security is just one aspect of a system. There is no particular reason for Linux to prioritize it above everything else, no matter what twitter infosec drama queens believe.
Obviously the fact that infosec people are quite often insufferable does not help their case.
If I were an average consumer, I would care much more about my device being secure, than having real time audio.
It's not even a choice between better security and real-time audio, since the average consumer doesn't even know about that unless specifically called out by marketing. For phones it's about what looks better, both physically and digitally. It's about how the emojis look, how good the pictures the camera takes look (or how good you're told they look), and how responsive and smooth the screen movements are.
The average consumer goes off what they can immediately see and what they're told by marketing, and by what they feel social pressure to buy. The discerning technical expert goes off marketing (but a different set of claims), and a bit more of a discerning eye, and while far more knowledgeable than the average consumer, is still mostly driven by hearsay.
The number of people with enough knowledge to actually make a real data driven choice is probably much less than 0.0001% of people, and that's far from average. I'm not one of them, but I can look at the systems often affected, make some assumptions about how many people know enough about them to speak usefully on risks they actually have, and do some napkin statistics to know almost nobody else is either, even here.
It's easy to call out the average consumer, but truthfully, the last time you bought a phone or computer, how deeply did you analyze the actual security considerations to do with the different aspects of the system, and how much did you rely on what some site told you, trusted recommendations, what you already preferred, and your hunch was which was better? How many millions of lines of code are involved in these systems now? How could you, or any of us actually do anything other than that?
If you were, you would behave like one, i.e. not care that much (if at all) about security.
What you are saying is "I do care about my device being secure".
Perhaps, the average person would be more upset/notice if they were negatively impacted as the result of a security issue, than if some feature, e.g. real time audio were missing, which I'm sure no one would even notice.
If you're system gets p0wned there is hardly any audio to play.
macOS, iOS and Windows security improvements, while being the musicians choice for real time audio, show it is possible to put security first, while offering a good audio stack.
Linux distributions make up the majority of public web and database servers and approximately none of the real-time audio players, is that not a “particular reason” to prioritise security over real-time audio?
It's bad enough that syzbot finds fifty serious bugs per hour, but I'll relay a personal anecdote. Earlier this year I wagered a colleague that I could open up the source of the 4.10 kernel (the one that was once current in Ubuntu 16) and find an obvious defect in less than an hour. It actually only took me about 15 minutes, to find a deadlock in the squashfs that was triggered by kmalloc failure and an error path via goto, which of course nobody should ever use. And while I'm reading it I'm just thinking to myself that this is the worst program I've ever seen and it would never pass a code review at my workplace, but it's out there right now running on billions of computers.
I hate that people keep peddling this nonsense because they wrote a little C and read a headline about “goto considered harmful”, which is a gross oversimplification and a BAD piece of “wisdom” that for some reason won’t die. This is how serious handling in C is done. Please stop repeating this tired trope.
Different ballgame from the subject of Dijkstra's manifesto.
Go, which is also known for its terrible error-handling.
This is the sense in which the Linux kernel uses goto.
Well written code is the best code. Some well written code uses goto. Some not well written code doesn't use goto
Oh man, can I put that on a t-shirt?
The other half of the problem is the companies that actually use these garbage dump forks and build products on top of them.
For me, getting the SoCs and chips we use running on latest upstream kernels was a high priority in platform bringup.
I only used SoC vedors' garbage dump SDKs for quick testing & some reference. And chip vendors' drivers I ported straight to upstream git version.
Of course this isn't how it goes in companies where "shit to market" is top priority.
The problem is there are so many of those.
As far as I know, no one is doing anything with the syzbot bugs against stable kernels directly, since no company using Linux is paying anyone to do it as their job. But some are getting fixed; e.g., some get reported against mainline too, then fixed and backported.
A weekly report with some easy to understand graphs would probably convince more people to work on these bugs.