Google Project Zero discovers a cache invalidation bug in Linux memory management, Ubuntu and Debian remain vulnerable

“Raise your game on merging kernel security fixes, you’re leaving users exposed for weeks”
-Jann Horn to maintainers of Ubuntu and Debian

Jann Horn, the Google Project Zero researcher who discovered the Meltdown and Spectre CPU flaws, is making headlines once again. He has uncovered a cache invalidation bug in the Linux kernel. The kernel bug is a cache invalidation flaw in Linux memory management that has been tagged as CVE-2018-17182.
The bug has been already reported to Linux kernel maintainers on September 12. Without any delay, Linux founder, Linus Torvalds fixed this bug in his upstream kernel tree two weeks ago. It was also fixed in the upstream stable kernel releases 4.18.9, 4.14.71, 4.9.128, and 4.4.157 and  3.16.58. Earlier last week, Horn released an “ugly exploit” for Ubuntu 18.04, which “takes about an hour to run before popping a root shell”.

The Bug discovered by Project Zero

The vulnerability is a use-after-free (UAF) attack. It works by exploiting the cache invalidation bug in the Linux memory management system, thus allowing an attacker to obtain root access to the target system. UAF vulnerabilities are a type of ‘memory-based corruption bug’. Once attackers gain access to the system, they can cause system crashes, alter or corrupt data, and gain privileged user access.
Whenever a userspace page fault occurs, for instance, when a page has to be paged in on demand, the Linux kernel has to look up the Virtual Memory Area (VMA) that contains the fault address to figure out how to handle the fault. To avoid any performance hit, Linux has a fastpath that can bypass the tree walk if the VMA was recently used. When a VMA is freed, the VMA caches of all threads must be invalidated – otherwise, the next VMA lookup would follow a dangling pointer. However, since a process can have many threads, simply iterating through the VMA caches of all threads would be a performance problem.

To solve this, both the struct mm_struct and the per-thread struct vmacache are tagged with sequence numbers. When the VMA lookup fastpath discovers in vmacache_valid() that current->vmacache.seqnum and current->mm->vmacache_seqnum don’t match, it wipes the contents of the current thread’s VMA cache and updates its sequence number.

The sequence numbers of the mm_struct and the VMA cache were only 32 bits wide, meaning that it was possible for them to overflow.  To overcome this, in version 3.16, an optimization was added. However, Horn asserts that this optimization is incorrect because it doesn’t take into account what happens if a previously single-threaded process creates a new thread immediately after the mm_struct’s sequence number has wrapped around to zero.

The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic.

Horn has raised concerns that some Linux distributions are leaving users exposed to potential attacks by not reacting fast enough to frequently updated upstream stable kernel releases.

End users of Linux distributions aren’t protected until each distribution merges the changes from upstream stable kernels, and then users install that updated release.

Between these two points, the issue also gets exposure on public mailing lists, giving both Linux distributions and would-be attackers a chance to take action.

As of today, Debian stable and Ubuntu releases 16.04 and 18.04 have not yet fixed the issue, in spite of the latest kernel update occurring around a month earlier. This means there’s a gap of several weeks between the flaw being publicly disclosed and fixes reaching end users. Canonical, the UK company that maintains Ubuntu, has responded to Horn’s blog, and says fixes “should be released” around Monday, October 1.

The window of exposure between the time an upstream fix is published and the time the fix actually becomes available to users is concerning. This gap could be utilized by an attacker to write a kernel exploit in the meantime. It is no secret that Linux distributions don’t publish kernel updates regularly.

This vulnerability highlights the importance of having a secure kernel configuration. Looks like the team at Linux needs to check and re-check their security patches before it is made available to the public.
You can head over to Google Project Zero’s official blog page for more insights on the vulnerability and how it was exploited by Jann Horn.

Read Next

NetSpectre attack exploits data from CPU memory

SpectreRSB targets CPU return stack buffer, found on Intel, AMD, and ARM chipsets

Meet ‘Foreshadow’: The L1 Terminal Fault in Intel’s chips