How the Linux kernel balances the risks of public bug disclosure

Last month a serious Linux Wi-Fi flaw (CVE-2019-17666) was uncovered that could have enabled an attacker to take over a Linux device using its Wi-Fi interface. At the time it was disclosed Naked Security decided to wait until a patch was available before writing about it.

Well, it’s been patched, but the journey from discovery to patch provides some insights into how the Linux open-source project (the world’s largest collaborative software development effort) manages bug fixes and the risks of disclosure.

The Linux community worked hard last month to patch a bug in one of the operating system’s wireless drivers. The bug lay in RTLWIFI, a driver used to run Wi-Fi chips produced by processor manufacturer Realtek.

To be vulnerable to the bug, a device would have to include a Realtek Wi-Fi chip. These processors can be found in everything from Wi-Fi access points and routers through to some laptop devices explained the person that found it, GitHub’s principal security researcher Nicolas Waisman.

If a device does contain this chip, the consequences could have been serious, he told Naked Security at the time:

You could potentially obtain remote code execution as an attacker.

An attacker in radio range of the device could send a packet using a Wi-Fi feature called Wi-Fi Direct, which enables devices to talk to each other directly via radio without using a central access point. The attacker could add information to the packet that would trigger a buffer overflow in the Linux kernel.

Given that Realtek chips turn up in all kinds of equipment including routers and laptops, the bug seemed like a pretty big deal. It’s also an old one – it’s been in the Linux codebase since 2013.

Waisman – a security researcher of note with a good reputation and a responsible outlook – revealed the bug before the Linux team had fixed it, which had us scratching our heads and wondering why he’d do that.

On Tuesday 15 October 2019 he notified the group via security@kernel.org, a private email list. Two days later he released it to the public via Twitter on 17 October. It would be almost three weeks before the security team’s patch appeared in v 5.3.9 of the Linux kernel on 6 November.

Found this bug on Monday. An overflow on the linux rtlwifi driver on P2P (Wifi-Direct), while parsing Notice of Absence frames.
The bug has been around for at least 4 years https://t.co/rigXOEId29 pic.twitter.com/vlVwHbUNmf

— Nico Waisman (@nicowaisman) October 17, 2019

The answer to why he did that was that after he submitted the bug report to the private security@kernel.org mailing list, as per standard practice, the Linux security team sent the code for a proposed patch to the publicly viewable Linux Kernel and Linux Wireless mailing lists. Another public patch proposal followed two days later.

Waisman took the exposure of this code as a form of public disclosure. He told us:

As soon as it hits that mailing list, it means that everyone that is monitoring that mailing list knows about the vulnerability.

Waisman hadn’t produced exploit code for this bug. However, someone else might, he said. He worried that someone could reverse-engineer a zero-day bug by watching patch proposals like the ones flowing over the public mailing list.

By announcing it on Twitter, he was following what he believed were appropriate responsible disclosure guidelines, enabling a greater number of people to take avoidance measures (basically turning off their Wi-Fi functionality) until a patch became available. A report by Mitre (which maintains the CVE database) appeared on the same day with a link to the public mailing list, and the company assigned it a CVE (CVE-2019-17666).

Was he right to worry? Does the community see the publication of patch proposals before their inclusion in the mainstream kernel branch as a security risk? There is a level of risk involved, admit senior organizers on the Linux kernel team.

Greg Kroah-Hartman, a Fellow at the Linux Foundation responsible for the Linux kernel stable releases, told us that the community does have procedures in place to keep bug discussions under wraps until a patch is ready:

For some issues, yes, it is good to do the work originally on the issue on the security@k.o list and then when it is ready, publish it and merge it like normal. That happens all the time.

So, if a bug is big and ugly enough, the team will keep the discussion on the private list.

There are also extra measures that the Linux kernel team can take to shield discussions of very serious bugs. There’s a private mailing list (described here) for communicating with individual Linux distribution vendors, giving them time to prepare kernel patches in advance of public disclosure.

Eventually, though, the code for a patch will have to make it onto the public repositories that house the source code for the Linux kernel. Making its way through that forest of different patches-in-waiting is a complex process. Kroah-Hartman:

There is no way to “hide” our work or patches as everything we do is released publicly in our trees. So yes, if you really wanted to see what is ‘broken’ in Linux, you ‘just’ watch everything that is merged into the kernel tree as it has hundreds of fixes for problems every week.

Linux has a mainline repository, maintained by the operating system’s creator Linus Torvalds. Before a patch makes it into that repo, though, it typically has to go through one of many subtrees, maintained by ‘lieutenants’, addressing different subsystems like networking and memory management.

The maintainers do their own quality control, accepting or rejecting patches for their own trees. Then they wait for an appropriate ‘merge window’, collect a handful of the patches that have made it into their tree, and offer them to Torvalds for possible inclusion into the mainline. Acceptance is at his discretion.

The mainline spits out a new ‘minor’ version of the Linux kernel every eight weeks or so and at the time of writing, the version that contains a fix for CVE-2019-17666 – version 5.4 – is still a week or two from being released.

However, when the security fix was accepted into the mainline on 23 October 2019 it received one of the green lights it needed to be back-ported to older versions of the kernel. An update to version 5.3 of the kernel, the current stable version, appeared on 6 November 2019 in the form of 5.3.9.

As Kroah-Hartman implies, watching all the trees to find patches for juicy looking bugs would be a difficult job, but it doesn’t sound impossible for a well-resourced adversary, especially thanks to the use of something’ called ‘-next trees’, which collect likely patches for the next mainline merge window.

Turning those bug fixes into workable, usable exploits would ad considerably to the adversary’s workload too, but it still leaves them with a difficult job, rather than an impossible one.

So, this bug became public knowledge before a patch was available because the person that found it disagreed with exposure decisions made by the folks that maintain the kernel. Everyone had the best interests of the community at heart, and now there’s a patch which will percolate to most users via numerous kernel distributions.

Of course, it’s one thing for a patch to be available and quite another for users to actually apply it. So, for fans of the wlan0 interface the usual advice applies: patch early, patch often.