The case of the prematurely freed SKB

CVE-2017-6074 is the vulnerability identifier for a use-after-free bug in the kernel's network stack. This vulnerability is apparently exploitable in local privilege-escalation attacks. The problem, introduced in 2005, is easily fixed, but it points at a couple of shortcomings in the kernel development process; as a result, it would not be surprising if more bugs of this variety were to turn up in the near future.

One of the network subsystem's core data structures is the sk_buff structure, which often goes by the name SKB. This complex structure contains and describes a packet for its entire life cycle in the kernel. As with many kernel data structures, SKBs are reference-counted. Whenever some kernel function takes a reference to an SKB, it increments the internal reference count; the reference is released by decrementing that count. As long as the count is nonzero, a reference to the SKB exists somewhere in the kernel, so the structure itself needs to continue to exist.

Normal kernel conventions call for the existence of a pair of functions, ending in _get() and _put(), to acquire and release a reference to a data structure. Thus, for example, a reference to a kref structure is obtained with kref_get() and released with kref_put(). The networking layer does provide skb_get() which, as expected, increments the reference count on an SKB. There is also an skb_put(), but it has nothing to do with reference counts at all; instead, it increments some internal pointers to reflect that some data has been added to the packet. To release a reference to an SKB, one calls one of:

    void kfree_skb(struct sk_buff *skb);
    void consume_skb(struct sk_buff *skb);
    void dev_kfree_skb(struct sk_buff *skb);
    void  __kfree_skb(struct sk_buff *skb);

Both kfree_skb() and consume_skb() will decrement the reference count and, if the result is zero, free the structure. They differ only in how they affect the various network statistics; kfree_skb() implies that a packet was dropped, while consume_skb() implies that it was used in some way. The macro dev_kfree_skb(), intended for use in drivers, turns into a call to consume_skb().

__kfree_skb() is different: it frees the SKB unconditionally without even looking at the reference count. Needless to say, this looks like a hazardous thing to do with a reference-counted data structure. And, indeed, that is exactly where the DCCP protocol code went wrong: it called __kfree_skb() on an SKB that, with the right sequence of steps, had another reference on it, leading to a classic use-after-free vulnerability. The fix is a simple switch to consume_skb() instead.

A comment next to the __kfree_skb() implementation says: "This is an internal helper function. Users should always call kfree_skb". A quick grep shows 94 call sites to __kfree_skb() in the kernel, 46 of which are in device drivers. It is not entirely implausible to think that maybe one or two of those other calls might represent a similar bug. Clearly some auditing is indicated here, but it might also be time to review this somewhat irregular reference-counting API, which seems designed to create just this kind of vulnerability. There are also many places in the code where the SKB reference count is directly manipulated without using the accessor functions; those, too, seem relatively likely to harbor bugs.

It's worth noting that this API is far from new. The SKB reference count was added for the 2.2 kernel in 1999, and the distinction between kfree_skb() and __kfree_skb() was added with it, though the former was the only caller of the latter then. The 2.4 kernel saw more __kfree_skb() calls within the core networking code, but none in drivers. The slow spread of potentially dangerous __kfree_skb() calls is the result of an API decision made nearly twenty years ago.

Al Viro once said: "Bugs are like mushrooms - found one, look around for more." In this case, it is instructive to look at this fix to the TCP subsystem. Masayuki Nakagawa noticed a use-after-free problem in the TCP code resulting to an ill-advised call to __kfree_skb(). The problem was fixed (by calling kfree_skb() this time) — in 2007, just over ten years ago. Might this fix have been the sort of mushroom that called out for a wider search?

When the DCCP protocol implementation was merged in 2005, much of it was, shall we say, heavily influenced by the existing TCP code. So the function that had not yet been fixed by Nakagawa, called tcp_rcv_state_process(), found a strong echo in the new function dccp_rcv_state_process(); that, naturally, is the function that was patched, in a nearly identical way, to fix CVE-2017-6074. In other words, a mushroom was indeed found, but nobody thought to look in the copy-and-pasted DCCP code for a similar fungal invasion. An opportunity to fix a privilege-escalation vulnerability was lost ten years ago.

This particular vulnerability was eventually unearthed with the syzkaller fuzzer, and it is now fixed. Fuzzing is a valuable tool for the identification of problems like this. But it cannot replace the simple process of looking over the kernel code in search of bugs that are similar to those that have been recently identified. While our community values code contributions and the industry tends to support developers well, we fall down when it comes to this sort of mushroom hunting, with the result that relatively easily identified bugs remain in the code for a decade or more. It seems unlikely that the black-hat community is not making the effort to look for echoes of recently fixed bugs.

Over the last year or two, there have been signs that the kernel community is getting more serious about improving security. Some hardening work is finally making its way into the mainline, and tools like syzkaller are unearthing longstanding issues. But this vulnerability shows a couple of areas where the kernel community could be doing a lot better than it is: designing safer internal APIs and looking for repeated buggy patterns. If we truly want to be the most secure system out there, both the community and the companies that support it may want to think about how these shortcomings can be rectified.

Index entries for this article
Kernel	Security/Vulnerabilities
Security	Linux kernel

---

to post comments