Pixel 6 and Galaxy S22 affected by major new Linux kernel vulnerability

A seemingly major vulnerability has been discovered by security researcher and Northwestern PhD student Zhenpeng Lin, affecting the kernel on the Pixel 6 and 6 Pro and other Android devices running Linux kernel versions based on 5.10 like the Galaxy S22 series. Precise details for how the vulnerability works have not yet been published, but the researcher claims that it can enable arbitrary read and write, privilege escalation, and disable SELinux security protections — in short, this is a biggie. The researcher has verified to Android Police that Google was not informed of the vulnerability before its demonstration on Twitter.

None of the precise technical details behind how the exploit works have been released, but a video claiming to show the exploit used on a Pixel 6 Pro was able to achieve root and disable SELinux. With tools like that, a malicious actor could achieve a lot of damage.

Based on the few details shown in the video (which show some sort of script or executable scanning processes and then identifying what looks like a specific address or location), this attack may use some sort of memory access exploit to do its thing, potentially like the recent Dirty Pipe vulnerability that affected the Galaxy S22 series, Pixel 6 series, and some other devices that launched with Linux Kernel versions 5.8 on Android 12 and later. The researcher also states that all phones using v5.10 of the Linux Kernel are affected, which we have verified includes Samsung’s Galaxy S22 series. This may also include other recent Android devices which launched with Android 12.

You can check to see your phone’s kernel version pretty easily, if you’re worried, only versions 5.10+ should be affected.

Speaking to Lin over email, he has confirmed to Android Police that precise details for the vulnerability have not been publicly released. He further confirmed that Google was vulnerability informed of the details of the details after we originally spoke to him (and after the demonstration on Twitter), and there is no corresponding CVE yet.

Frequently, security researchers refrain from publicly disclosing details of any kind regarding vulnerabilities in a period that’s known as “coordinated vulnerability disclosure,” where security researchers only disclose an exploit to the public as a last-ditch effort to protect end-users if and when earlier attempts to reach the companies involved fail. For example, Google’s internal security research division (Project Zero) has a 90-day policy for a response on vulnerabilities that aren’t being actively exploited and a 7-day policy for those that are (plus an additional 30 days if patches land inside that window).

While the researcher hasn’t released a full set of instructions for how this vulnerability works, we don’t often see a public exhibition of a major vulnerability like this happen before the companies involved with it are informed. This could potentially affect things like bug bounty payouts.

Last year Google issued $8.7 million in bug bounty rewards, and currently the company says it pays up to $250,000 for kernel-level vulnerabilities, which this seems to be. The vulnerability may even qualify for other separate reward categories, but disclosing a vulnerability publicly before reporting it to Google can affect all that. Circumstances are reviewed on a case-by-case basis, but the published rules sound like disclosing the vulnerability on Twitter may preclude the typical reward even though the video does not fully describe how the vulnerability works. Google ultimately has the last say, and most researchers seem to err on the side of caution, withholding public disclosure until later.

Lin tells us he believes his demonstration is merely a proof of concept meant to warn end-users before it is patched, so they can try to protect themselves (though methods for that protection haven’t been offered), and will not constitute a violation of Google’s disclosure rules.

Google and Samsung have not yet responded to our inquiries regarding the vulnerability, so it’s not clear on what sort of schedule it might be patched. Given the timeline and how Google’s security patches work, we may not see this issue addressed until the September patch level at the soonest, and the relatively recent report submission could impose other delays. Other manufacturers may be able to pull a fix for the issue into their own patches early should one be available separately — Samsung seemingly did that in the case of Dirty Pipe earlier this year.