笔者作为初入安卓内核漏洞利用分析的从业者，自 CVE-2017-8890 这个漏洞被曝之后不久就开始研究其成因、原理、触发以及利用。至今遇到了无数问题，也解决了无数问题，于是记下这篇文章以做小结，一来对这段时间的工作学习做一个归纳总结，二来希望能对同样对安卓内核漏洞感兴趣的朋友有一些细节上的帮助。

    + 编号：CVE-2017-8890

    + 类型：double free

    + 位置：/net/ipv4/inet_connection_sock.c

    + 描述：

分析一个漏洞的原理，最直接的方法是从补丁入手。

CVE-2017-8890 的补丁如下所示：

可以看到这个补丁非常简单，只添加了一行代码，作用是将 inet_sk(newsk)->mc_list 置为 NULL。再结合漏洞类型为 double free，很容易得知应该是释放流程中对 mc_list 这个结构体的处理不当，导致了这个漏洞产生。那么这里比较关心的问题如下：

    + 这个对象是什么？

    + 对象在哪里产生？

    + 对象在哪里释放？

    + 为什么会产生漏洞？

通过源码分析和搜索引擎可以知道，mc_list 这个对象代表的是组播列表。其原型如下：

既然这个结构体是组播列表，那么很容易得知，当创建组播，加入组播的时候，很可能就会创建这个结构体。

通过前面的推测，加上内核源码分析，能够得出如下调用链，将会创建这个结构体。

用户态：

内核态：

知道了对象，创建流程，通过源码分析也能够找到释放的调用链。

用户态：

内核态：

PS：这里不得不说一下，我很佩服挖到这个漏洞的大佬，但是 【ADLab原创首发】“Phoenix Talon”in Linux Kernel —潜伏长达11年之久的内核漏洞 的两次对象释放写在不同的位置很误导人。之所以能够看到两次不同的释放，是因为 RCU 系统的存在，ip_mc_drop_socket 这个函数导致释放操作，真正的释放在 __rcu_reclaim。软中断是由于时钟中断导致，都是 RCU 释放流程中的正常操作。两次释放都在同一个点，都是由于用户态 close 导致的。

那么问题的关键来了，为什么会产生这个漏洞。

在搜集信息的过程中我们已经知道了这个漏洞是一个 double free，既然是 double free，那必然是一次创建，两次释放。但是从上面对象创建和释放的流程来看，并不能找到两次释放的点。

这个时候，漏洞描述中的一句话给出了分析方向：

在 accept 的时候，子对象会从父对象复制一份 mc_list。

但如果是复制的话，对象应该也会复制一份，那么对子对象和父对象都进行释放，应该是不会产生漏洞的。带着这样的疑问对源码进行了分析之后得到答案：

首先 mc_list 是 sock 对象的一个成员，并且是由 sock 中的指针所指向的对象

accept 的时候会把 sock 对象拷贝一份而不是 mc_list

由以上两点就能够解释漏洞为何产生了 —— 多个对象拥有了指向同一个对象的指针。

那么这个漏洞已经不是 double free 了，甚至可以是 X free，因为只要 accept 多次，那么就会有多个对象指向同一个 mc_list。

从上面的分析中我们已经得到了几个触发漏洞的关键点：

[课程]Android-CTF解题方法汇总！