2020-8 android kernel vulnerability

qualcomm：https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin
google：https://source.android.com/security/bulletin/2020-08-01

0x00 CVE-2020-0255

发生位置：

hooks.c的selinux_netlink_send()函数

补丁：

https://android.googlesource.com/kernel/common/+/fb73974172ff%5E%21/#F0

触发方法：

尝试构造多个netlink sock的数据包，发送给内核，填充struct sk_buff的data字段，当发送数据包多于一个时，触发netlink_send的hook函数，除了第一个数据包的nlmsghdr会被检测，其他的都可以绕过检测。

漏洞成因：

只对sk_buf的data字段中第一个nlmsghdr进行了检测。

修复方法：

通过sk_buf数据结构的len字段来循环检测，每次减去nlmsghdr的大小，知道检测完所有的nlmsghdr。

时间：

2005-4-16至2020-4-30

是什么：

selinux中关于发送netlink sock的hook函数。

0x01 CVE-2020-12464（6.7）

发生位置：

message.c的usb_sg_cancel()函数

补丁：

https://android.googlesource.com/kernel/common/+/056ad39ee925%5E%21/#F0

触发方法：

尝试用两个线程分别触发usb_sg_wait()函数，同时确保先触发的线程有urbs存活，来引起usb_sg_cancel和usb_sg_wait的race condition.

漏洞成因：

usb_sg_cancel中没有判断io的存活与否，直接对io进行了操作，导致io可能已经在另一个线程被usb_sg_wait给释放了。

修复方法：

在usb_sg_cancel中增加对io->count的引用，确保io的存活，同时在usb_sg_cancel中增加对io->complete的操作。

时间：

2008-1-30至2020-4-16

是什么：

发生linux USB 子系统的USB S-Glibrary

0x02 CVE-2019-16746（9.8）

发生位置：

nl80211.c的validate_beacon_head()函数

补丁：

https://android.googlesource.com/kernel/common/+/f88eb7c0d002%5E%21/#F0

触发方法：

NL80211是用netlink来交互的，所以应该需要构造一个netlink sock来触发驱动执行NL80211_CMD_START_AP指令。尝试在netlink sock中填充nlattr长度大于 u.beacon于ieee80211_mgmt的偏移大小，导致越界拷贝。

漏洞成因：

没有对nlattr数据进行检测

修复方法：

增加了validate_beacon_head来对nlattr进行检测。

时间：

2007-12-19至2019-10-1

是什么：

NL80211驱动

0x03 CVE-2020-11116（9.8）

发生位置：

wlan_hdd_assoc.c的hdd_send_ft_assoc_response()

补丁：

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=616c6046ec0e3801872996871df67a04472d3677

触发方法：

主机向客户端发送修改文件后缀名的请求，伪造pCsrRoamInfo结构体的nAssocRspLength，pCsrRoamInfo->nAssocRspLength - FT_ASSOC_RSP_IES_OFFSET大于IW_GENERIC_IE_MAX，会导致申请的buff空间出现越界拷贝，或者pCsrRoamInfo->nAssocRspLength小于FT_ASSOC_RSP_IES_OFFSET也会出现问题。

漏洞成因：

缺少对pCsrRoamInfo->nAssocRspLength长度的检查，只是简单的检查了是否为0。

修复方法：

增加对pCsrRoamInfo->nAssocRspLength最大值和最小值的检测。

时间：

2015-11-17至2019-12-30

是什么：

高通qcacld2.0和3.0驱动

0x04 CVE-2019-10527（7.8）

发生位置：

smem.c的多个函数

补丁：

https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=24159c63bd7893a6061a29e06e01b96f02543eb3

触发方法：

尝试远程触发qcom_smem_alloc函数，只要绕过smem_private_entry 的canary 就可以申请超过当前分区的entry结构。

漏洞成因：

没有对远程程序传来的参数进行足够的判断。

修复方法：

主要是参数的范围进行了检测，确保不会出现越界的情况。

时间：

2015-7-28至2019-7-8

是什么：

高通的IPC模块

0x05 CVE-2019-14117（7.8）

发生位置：

rmnet_map_data.c的rmnet_free_agg_pages和__rmnet_alloc_agg_pages

补丁：

https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=06d7c43e7e4e224ab96bb1e069d495a8dd95c60a

触发方法：

rmnet_free_agg_pages()函数能够释放所有的list中的agg_page，但是并没有在list中清除，所以可以直接两次调用rmnet_free_agg_pages，来触发UAF。

漏洞成因：

单单只是释放了agg_page对象，没有把list指向agg_page的指针置空，导致了UAF。

修复方法：

在rmnet_free_agg_pages增加list_del来清除list中的元素。同时在alloc_agg_pages时，对list进行初始化。

时间：

2013至2019-09-13

是什么：

高通的wlan通信模块相关，RmNet驱动

0x06 CVE-2020-11115（7.5）

发生位置：

rrm_api.c的rrm_fill_beacon_ies()

补丁：

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=df3267d03f18febbc3b9e5de6c1647133f11646e

触发方法：

设置(pBcnIes + 1)=0xfe或者更大的时候，当0xfe+2之后，pNumIes会出现整数溢出，导致(*pNumIes) + len) < pIesMaxSize)失效，所以无论如何qdf_mem_copy都会被执行。

漏洞成因：

pNumIes被定义为uint8_t ，而len被设置为了uint16_t，将len赋值给pNumles时会出现整数溢出。

修复方法：

增加len和BcnNumIes 的判断，用BcnNumIes 来限制len不会过大。

时间：

2015-11-17至2019-12-28

是什么：

高通WLAN模块rrm(无线资源管理)

0x07 CVE-2020-11118（7.5）

发生位置：

rrm_api.c的rrm_fill_beacon_ies()

补丁：

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=bf4774a59d24cc1d533f253de0e6e2fa1b154c4d

触发方法：

正常调用rrm_fill_beacon_ies()函数即可。

漏洞成因：

循环使用的BcnNumIes，每次循环都是BcnNumIes-len>0来作为循环的条件，但是由于最开始的两个字节是IE的头部，所以会导致循环次数增加一次。

修复方法：

BcnNumIes-len>=2来作为循环的条件。

时间：

2015-11-17至2020-03-05

是什么：

高通WLAN模块rrm(无线资源管理)

0x08 CVE-2020-11120（7.8）

发生位置：

eap_proxy_qmi.c下的多个函数。

补丁：

https://source.codeaurora.org/quic/la/platform/external/wpa_supplicant_8/commit?id=36a414abcf0c864460d8c3bf95a6fd070d9dbbd7

触发方法：

先创建相应的等待事件，在调用wpa_qmi_client_indication_cb()线程时会注册定时器延时执行__wpa_qmi_client_indication_cb，来释放callback data，在此之后，如果event loop执行到了等待事件，触发了callback函数，此时由于data被释放，所以基本为null。

漏洞成因：

eap_proxy 中对直接对callback所需的data进行了操作。

修复方法：

集中使用eap_proxy_clear_qmi_cb_data和eap_proxy_prepare_qmi_cb_data来对cb_data进行申请和释放。在eap_proxy_clear_qmi_cb_data和eap_proxy_prepare_qmi_cb_data中增加对cb_data为null的校验，并且用本地的data来单独进行处理eap_proxy 中对于data的操作，防止对callback中的data产生影响。

时间：

2019-10-14至2019-11-14

是什么：

高通eap(可扩展的身份验证协议？)代理qmi（用于ap和bp端交互的一种机制）通信

0x09 CVE-2020-3646（7.8）

发生位置：

dp_debug.c下的多个函数

补丁：

https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=44e73a133d6892b43bbb2ad1b5b04cd4b9e4bbc2

触发方法：

使用dp的debugfs来进行命令操作，以dp_debug_read_dpcd为例，当输入的count小于len时会导致copy_to_user导致缓存区溢出。

漏洞成因：

在进行copy_to_user时没有对长度进行检查。

修复方法：

增加检查，使用len和count中较小的长度作为拷贝的长度。

时间：

2017-08-18至2019-08-26

是什么：

图像显示（dp）的debugfs

0x0A CVE-2020-3647（7.8）

发生位置：

npu_debugfs.c的npu_debug_off_read和npu_debug_log_read

补丁：

https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=204925a38ea821f956d456aced12f5040ae66db5

触发方法：

用npu的debugfs来调用npu_debug_log_read或者npu_debug_off_read，以npu_debug_log_read为例，当remaining_to_end+debugfs->log_num_bytes_buffered大于count时，用户态的user_buf可能发生缓冲区溢出。

漏洞成因：

在进行copy_to_user时没有对长度进行检查。

修复方法：

npu_debug_log_read中对长度进行判断，选择debugfs->log_num_bytes_buffered，debugfs->log_buf_size - debugfs->log_read_index和count中最小的一个进行copy_to_user。npu_debug_off_read中增加对len和count的长度的判断。

时间：

至 2019-12-14

是什么：

npu的debugfs