Linux “got root” kernel bug patched after five years at large


You enter stormy waters when you compare security at the core of Linux with security inside Windows.

So, hold your breath and hang onto your hat.

Here’s a kernel bug in Linux that turned out to have been sitting there, Heartbleed style, awaiting discovery and exploitation for several years.

The vulnerability allows a buffer overflow in the Linux pty driver, short for “pseudo teletype” or “pseudoterminal.”

Ptys are, in the words of the relevant man page, “a pair of virtual character devices that provide a bidirectional communication channel.”

You can use ptys for all sorts of interprocess communication, but they are typically intended for use by software such as ssh, which gives you a secure shell; script, which keeps a transcript of your current terminal session (a sort-of honest-to-goodness keylogger); and screen, which lets you split a single terminal window into multiple virtual terminals.

In short, if you’re a Linux user, you probably use ptys a lot of the time.

Race conditions

The bug is what’s called a race condition, where two processes compete to get access to a resource, but end up clashing over it in a way that corrupts either or both accesses.

Here’s an example in the form of an analogy.

When I was a youngster, we were supposed to chant, when crossing the road, “Look right, look left, look right again.” (In a country that drives on the left, you are in more imminent danger from traffic to your right as you step off the kerb.)

That ditty always worried me, because of the race condition.

What if, while you’re looking right again, a car comes into range on the left that you didn’t see before?

Ideally, what you want is a Pelican crossing, where you press a button that toggles a traffic light so that traffic is required to stop, and pedestrians are allowed to cross.

In computer science, a Pelican crossing is known as a mutex, short for mutual exclusion.

That’s a global resource, managed by the operating system, that brackets a section of code so it that can only be entered by a single thread of execution at a time.

Once you get hold of the mutex (the little green man), you’re free to access the resource; when you’re done with it, you give it back to the operating system (and your little man goes red) so the next guys can have a go at crossing the road in their turn.


Here’s some pseudocode to show the sort of problem that happened in the Linux kernel.

Imagine two concurrent threads of execution, sharing the same memory space, so that the variables buffer (a storage array for eight objects) and bcount (how many objects are already in the buffer) are common to both threads.

If they hit the same piece of code, where the buffer gets updated, at about the same time, then the instructions they execute will be interleaved and we run the risk of a race condition on the buffer.

We might be lucky:

Or we might not:

In regular usage, even heavy usage, the “bad luck” scenario might never show up, but with clever timing (or simply with many repeated attempts), an attacker could find a way to hit the jackpot by overwriting memory.

In the best case, the code will crash; in the worst case, it will begin to misbehave or actually give control to the attacker.

The bottom line

An attacker who can run code of his choice in the kernel can easily promote himself to the all-powerful Linux user called root.

A proof of concept exploit is available online, so this is a bug to patch as soon as you can.

If you’re in the habit of building your own kernel, you can apply the patch now, which makes the pty code use a Pelican crossing to write to its output buffer:

Or you can wait until your Linux distro publishes an update and then get busy.

Just don’t say, “This would never have happened on Windows.”