Lucene search

HistoryFeb 23, 2017 - 12:00 a.m.

Snow hidden for 11 years: Linux kernel DCCP double-free privilege escalation Vulnerability, CVE-2017-6074-a vulnerability warning-the black bar safety net






Vulnerability description
Vulnerability ID: CVE-2017-6074
Vulnerability discovered by: Andrey Konovalov
Vulnerability hazards: by an unprivileged process to obtain the kernel code execution and thus enhance permissions
Scope of impact: Linux kernel version>2.6.18(2006 9 months). But DCCP(datagram congestion Control Protocol)was first in the 05 year 10 on Linux kernel version 2. 6. 14 in support. Currently the vulnerability and 2017 years 2 months 17 repair. For details, please see the
Vulnerability details
Datagram congestion Control Protocol DCCP is a transport layer UDP new transport Protocol developed for transmitting real-time business. He is one can carry out congestion control for non-reliable transmission Protocol, and at the same time provide a variety of congestion control mechanisms at the start of communication by the user to negotiate options.
More detail description:
This vulnerability requires that a kernel compile time on CONFIG_IP_DCCP, many linux distributions by default.
In the current DCCP implementations, if the dccp_rcv_state_process in dccp_v6_conn_request returns“success” ,dccp_type for DCCP_PKT_REQUEST packet to the skb will be__kfree_skb mandatory release.
However, if in the socket on the set IPV6_RECVPKTINFO, the skb address will be saved in ireq-> pktopts, and then dccp_v6_conn_request will increase skb reference count, so the skb is still in use. However, it will still be in dccp_rcv_state_process is released.
The repair way is to call consume_skb, it takes the skb->users, and not jump to discard and then calls__kfree_skb。
diff --git a/net/dccp/input. c b/net/dccp/input. c
index ba34718…8fedc2d 100644
-– a/net/dccp/input. c
+++ b/net/dccp/input. c
int dccp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
struct dccp_hdr *dh, unsigned int len)
struct dccp_sock *dp = dccp_sk(sk);
struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
const int old_state = sk->sk_state;
int queued = 0;

if (sk->sk_state == DCCP_LISTEN) {
if (dh->dccph_type == DCCP_PKT_REQUEST) {
if (inet_csk(sk)->icsk_af_ops->conn_request(sk,
return 1;
- goto discard;
+ consume_skb(skb);
+ return 0;
if (dh->dccph_type == DCCP_PKT_RESET)
goto discard;
/* Caller (dccp_v4_do_rcv) will send Reset */
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
return 1;
} else if (sk->sk_state == DCCP_CLOSED) {
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
return 1;
To take advantage of this double-free, you can put it into a use-after-free:
//First release
//In the dccp_skb the same position is assigned to another object:
some_object = kmalloc()
//The second release, the actual release is some_object object
In this case some_object holding a dangling pointer, so it is constructed out of a UAF. The attacker can control the object, at the same time by using the kernel heap spray technique writes any data to be overwritten object.
If the cover object is there any can trigger the function pointer, the attacker can be in the kernel to execute arbitrary code.
Linux is the release version for the vulnerability related information
debian: the
redhat: the
ubuntu: the
suse: the

the PoC will publish in a few days,please update your linux kernel
Repair recommendations
Recommends that users update to the latest release to fix this vulnerability