由于上篇文章(Linux内核代码审计之CVE-2018-9568(WrongZone))是针对网络子系统的，因此这篇也还是找一个网络子系统的漏洞去审计。本文同样是学习 Linux 内核漏洞时的记录，从草稿箱中翻出，稍加修改后在此分享一下。

这次选的漏洞是CVE-2018-5703，是syzcaller扫出来的，漏洞报告见：

https://groups.google.com/forum/#!msg/syzkaller-bugs/0PBeVnSzfqQ/5eXAlM46BQAJ

tcp_v6_syn_recv_sock这个函数是定义在虚函数表的syn_recv_sock:

类似的虚函数表在分析上一个漏洞的时候有见过，调用的链路如下:

首先需要理解什么时候会调用到syn_recv_sock，那就需要了解ops虚函数表的作用，connection_sock_af_ops定义在include/net/inet_connection_sock.h:

如注释所说，包含地址（Address Family）相关的TCP函数，connection sock表示带连接的sock，定义如下：

例如，TCP sock就内联了connection sock作为第一个元素，所以tcp_sock指针可以转换成inet_connection_sock指针而没有任何副作用。

既然漏洞出在这个函数，我们就需要先了解这个函数实现的功能。由于其是connection sock的函数，且字段为syn_recv_sock，因此有理由猜测这是TCP协议中接收SYN报文的回调函数。根据TCP协议的状态机，SYN报文会在两种状态下转换，分别是：

tcp_v6_syn_recv_sock顾名思义也就是IPv6的tcp链接接收到SYN的处理流程，调用堆栈如下：

虽然有实现的大致文档，但是关于函数细节的文档通常是没有的，所以，RTFSC！函数原型：

request_sock包含了一次连接请求所需要的信息：

首先检查协议是不是IP协议，如果是的话表示当前地址是IPv4-to-IPv6的地址，转换成IPv4地址后按照IPv4处理：

如果是正常的IPv6协议，则走ipv6的处理流程:

在分析WrongZone漏洞的时候也看到过类似的流程，TCP连接建立会创建新的sock对象newsk，所以用户空间accept在收到新连接时会返回对应newsk的文件描述符。

回忆一下WrongZone中的类型混淆漏洞，是由于在运行过程中ipv6 sk的sk_prot被修改了，而新建的sock所使用的slab依赖于sk->sk_prot->slab，从而导致克隆的实际上是修改过类型的sock，与原始sk类型不一致(sk->sk_prot_creator)，导致类型混淆。

那么这里是否也是同样的问题呢？其实在翻漏洞报告的时候不小心瞄到了一句话：

tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads to this bug.

修改sk->sk_prot从IPv6改为IPv4，效果和IPV6_ADDRFORM一样！后者的实现：

tls_init的实现：

所以，newsk其实是从TCPv4 Slab中分配的，KASAN的告警触发在下面代码的memcpy处：

np为inet6_sk(sk)，newnp为inet6_sk(newsk)，inet6_sk定义如下：

tcp6_sock结构：

发现问题了吗？newsk被强制转换成了tcp6_sock，后者的大小如下：

tcp_sock的slab object_size正好是2528，因此强制转换类型之后inet6部分就越界了。事实上KSAN的报错也是如此：

一个还没解释的问题是，内核如何进入到tls_init? 查看堆栈：

可以看到是通过setsockopt，关于kernel对TLS的支持见文档 https://www.kernel.org/doc/html/latest/networking/tls.html 。简单来说，进入方法就是：

该漏洞的修复如下：

在TLS ULP（upper level protocol）中做了进一步限制，明确指定不支持LISTEN状态的socket设置TLS，虽然是偷懒的做法，但是work。

说起来这是第二次遇到因为sock的prot类型改变导致的漏洞了，这两个漏洞还是几乎相同时间报出来的。

会不会还存在其他类似的漏洞？简单地grep：

第二行引起了WrongZone漏洞，第四行引起了本文的漏洞，第一行是创建的时候（sk_alloc），第三行呢？同样是在IPV6_ADDRFORM的处理分支中，与WrongZone漏洞并列，在UDP的分支中。

也就是说TCPv6 UDP的socket也会在运行时变化类型（udpv6_prot <--> udp_prot/udplite_prot），这会导致类似的类型混淆问题吗？ 这需要跟踪UDP sock的整个生命周期，以及所有可能触达的分支。

当然，根据前面两个漏洞的pattern，范围还可以缩小一些。前面两个漏洞都是发生在sock复制的时候sk_prot_creator没变导致的类型混淆。对于TCP而言，克隆发生在inet_csk_clone_lock，csk表示这是针对connection sock的，内部调用的是sk_clone_lock，搜索所有调用处：

只有inet_csk_clone_lock一处调用，所以可以认为UDP协议是不受同类漏洞影响的。

如果不看报告内容的话，即便知道这是一个类型混淆，一开始是找不到这个漏洞点的，根本原因是不知道内核对于 socket 还支持 tls 的功能，而且 tls 还可以改变内核 sock 的 prot 类型。这个例子也可以看出代码审计并非万能(毕竟这是 syzcaller fuzz 出来的)，但通过审计形成的理解，我们可以通过简单的 grep 找到更多同类的漏洞，比如上面 UDP6 的潜在类型混淆。

虽然这次没有找到真正的漏洞，但要相信这不过是投入产出比的问题，漏洞只是理解系统的副产品，做之前想好自己真正想要的是什么就可以了。

PS:

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！