Zack's Kernel News

Chronicler Zack Brown reports on the latest news, views, dilemmas, and developments within the Linux kernel community.

- By Zack Brown

The Bug That Wasn't There

Someone named Gene who works at Sapience reported a bug in the stable version of the Linux kernel. This is normally a pretty big deal – not because the stable kernel is never supposed to have bugs, but because any bugs that are found there will be tackled and fixed immediately. The development kernels, on the other hand, are slightly more tolerant of bugs lasting until the next release cycle. And of course, release candidate (RC) kernels are the most likely to have bugs, because they often introduce new features that have been tested by relatively few people.

Gene reported that the kernel’s driver for the Xe graphics card from Intel was dereferencing a piece of memory unsafely – in other words, it tried to access that memory without verifying that it could actually do so. This could have effects that range from executing unknown code (which could be a security hole) to completely crashing the entire system. In Gene’s case, the kernel only produced a warning. Still, potential security holes must always be plugged, even if it means removing the feature that includes the security hole.

Gene said if no one saw a solution right away, he’d do a git bisect soon to identify exactly which kernel version introduced the bug. Bisecting is a standard tool in code development – essentially you go halfway from where the bug is to where it is known not to be and check if it’s still there. Then you keep cutting the distance by half and checking for the bug each time. This approach leads you very quickly to the culprit. For example, if you had 1,000,000 patches that might contain the bad code, you could nail down the right one in at most 20 tries.