jhash（）计算密钥的核心参数需要哪几个

　　ps：谷歌最好看英文的通告，英文和中文通告不是同步更新就很难受，中文版的晚很久，我找说怎么找老半天找不到，还被师傅怼了，原来大家都看的英文文档，就我看的是中文。。。另外0x03到0x09的漏洞暂时没有评分出来。
　　发生位置：
　　i915_gem_execbuffer.c的i915_gem_execbuffer2_ioctl（）函数
　　补丁：
　　触发方法：
　　用ioctl调用i915_gem_execbuffer2_ioctl传入的data参数中伪造一个非法地址，可能造成任意地址写。
　　漏洞成因：
　　i915_gem_execbuffer2_ioctl（）中使用的用户空间指针user_exec_list 未使用access_ok（）检查可用性。
　　修复方法：
　　把access_ok（）集成到user_access_begin（）函数中，确保每个用户空间地址被真正使用前会被进行有效性检查。
　　时间：
　　是什么：
　　i915显卡驱动
　　0x01 CVE-2019-18282（5.3）
　　发生位置：
　　net/core/flow_dissector.c中的一系列函数
　　补丁：
　　触发方法：
　　jhash（）计算密钥的核心参数需要三个，一个是hashrnd 被设置为__read_mostly类型，存储在cache中，可能需要暴力破解。第二个和第三个分别是由sk_buff 的结构组成的key的数据和长度，key值被skb_flow_dissect_flow_keys（）函数计算，sk_buf应该需要通过抓取数据包来计算。
　　漏洞成因：
　　ipv6 udp的auto flowlabnel使用了jhash（）来运算自己的一个32位的密钥，而且该哈希随机数的值在系统启动之后就不会变化了，容易被破解，这个密钥的主要作用是用来作为数据包的一种识别码。
　　修复方法：
　　不使用jhash来计算密钥，更改为siphash（）哈希函数，siphash（）是一种加密型伪随机函数。
　　时间：
　　是什么：
　　ipv6的udp数据包构造函数
　　0x02 CVE-2019-20636（6.7）
　　发生位置：
　　drivers/input/input.c的input_set_keycode函数
　　补丁：
　　触发方法：
　　ioctl使用参数EVIOCSKEYCODE来进行input_keymap_entry 结构体的设置，input_keymap_entry 决定old_keycode的大小，old_keycode 要大于KEY_MAX即0x2ff。
　　漏洞成因：
　　没有对old_keycode 值进行判断，在input_set_keycode（）函数当old_keycode 的值过大的时，可能会导致越界写，在input_default_setkeycode（）函数中使用clear_bit（）来清空过大的keycode会导致驱动设备损坏。
　　修复方法：
　　增加一个if语句来判断old_keycode 的最大值，在input_default_setkeycode中如果old_keycode 大于KEY_MAX的值，则不对过大的部分使用clear_bit（）函数来清空，在input_set_keycode中如果old_keycode 过大直接弹出警告并且退出当前函数。
　　时间：
　　是什么：
　　input驱动（所有的输入）
　　0x03 CVE-2020-3698（unknown）
　　发生位置：
　　主要是sme_api.c的sme_update_dsc_pto_up_mapping（），还有一写dscp_to_up_map相关的函数
　　补丁：
　　触发方法：
　　主要调用sme_update_dsc_pto_up_mapping（）函数的位置是hdd_wmm_assoc（），用来返回的是高通QDF驱动的状态，触发漏洞需要伪造恶意wifi，伪造元素个数大于0x40的数据包的dscp_exceptions，向目标主机发送。
　　漏洞成因：
　　在dscp_to_up_map进行范围检查的时候使用的是不等于0xff，dscpmapping的最大元素个数只有0x40，导致dscpmapping被越界写。
　　修复方法：
　　sme_update_dsc_pto_up_mapping（）修改判断条件，从不等于0xff变为小于等于0x40，同时换了个宏定义，把WLAN_MAX_DSCP 定义为0x3f，并且从原先的wlan_hdd_wmm.h修改到了sme_qos_api.h文件。
　　时间：
　　2015-11-17至2020-01-07
　　是什么：
　　高通的WLAN模组qcacld-3.0，该漏洞函数主要是 QoS 和数据包的DSCP映射。
　　影响设备：
　　APQ8009， APQ8017， APQ8053， APQ8096AU， APQ8098， MDM9150， MDM9206， MDM9207C， MDM9607， MDM9650， MSM8905， MSM8909W， MSM8917， MSM8920， MSM8937， MSM8940， MSM8953， MSM8996AU， Nicobar， QCA6174A， QCA6574AU， QCA9377， QCA9379， QCM2150， QCN7605， QCS405， QCS605， QM215， SA6155P， Saipan， SC8180X， SDA845， SDM429， SDM429W， SDM439， SDM450， SDM630， SDM632， SDM636， SDM660， SDM845， SDX20， SDX55， SM8150， SM8250， SXR2130
　　0x04 CVE-2020-3699（unknown）
　　发生位置：
　　wlan_hdd_assoc.c的hdd_send_re_assoc_event（）
　　补丁：
　　触发方法：
　　最外层的调用函数为hdd_connect_done，创建恶意wifi接入点，尝试与目标通过IEEE 802.11链路认证来连接，传输的数据包需要控制roam_info字段，确保roam_info-》nAssocRspLength大于IW_GENERIC_IE_MAX +FT_ASSOC_RSP_IES_OFFSET。
　　漏洞成因：
　　rsp_rsn_ie是给的一块用来存放响应的IE的固定缓冲区，但是没有对IE的大小进行判断，导致roam_info中的IE向缓冲区拷贝时可能造成越界拷贝。
　　修复方法：
　　增加了两处防护，一处是判断了目标IE的大小要至少大于FT_ASSOC_RSP_IES_OFFSET，另一处是在拷贝之前，确保拷贝长度小于最大的缓冲区大小IW_GENERIC_IE_MAX。
　　时间：
　　是什么：
　　高通的WLAN模组qcacld-3.0，主要的漏洞函数是设备用来发送重新关联响应给客户端，为的是与客户端完成IEEE 802.11链路认证中的PMK_R1密钥生成，主要涉及的是RSN IE（IEEE 802.11i引入的健壮安全网络和强制AES加密的信息元素）
　　影响设备：
　　APQ8009， APQ8017， APQ8053， APQ8096AU， MDM9206， MDM9207C， MDM9607， MDM9640， MDM9650， MSM8905， MSM8909W， MSM8917， MSM8920， MSM8937， MSM8940， MSM8953， MSM8996AU， Nicobar， QCA6174A， QCA6574AU， QCA9377， QCA9379， QCM2150， QCN7605， QCS405， QCS605， QM215， SA6155P， Saipan， SC8180X， SDA845， SDM429， SDM429W， SDM439， SDM450， SDM630， SDM632， SDM636， SDM660， SDM845， SDX20， SDX55， SM6150， SM7150， SM8150， SM8250， SXR2130
　　0x05 CVE-2019-10580（unknown）
　　发生位置：
　　qseecom.c的qseecom_register_listener（）和qseecom_unregister_listener（）
　　补丁：
　　触发方法：
　　调用qseecom_scm_call2，其中svc_id为QSEOS_REGISTER_LISTENER和QSEOS_DEREGISTER_LISTENER分别可以注册和注销data（struct qseecom_dev_handle）。调用注册函数两次，调用注销函数一次，将目标放入注销队列，关闭fd，释放data，然后重新开启fd，再次关闭fd来触发UAF。
　　漏洞成因：
　　qseecom_unregister_listener（）中并没有对需要的data进行判断，如果data已经被释放，在次调用qseecom_unregister_listener（）可能会造成UAF。qseecom_register_listener（）在最开始就给data-》listen_id赋值，此时data还未注册成功。
　　修复方法：
　　在qseecom_unregister_listener（）函数开始处增加判断语句来判断data（struct qseecom_dev_handle） 的released字段是否被置为1，如果被置为1就放弃把该data增加进注销的列表中。同时在qseecom_register_listener（）中需要成功注册data，才会赋予data对应的id。在qseecom_release（）函数中也增加判断函数，只有注销失败，才设置free_private_data 为false。
　　时间：
　　是什么：
　　QSEECOM驱动（高通安全执行通信驱动），用来增加和卸载一些TrustZone的TrustApplcation
　　影响设备：
　　MDM9607， MSM8909W， Nicobar， QCM2150， QCS405， QCS605， Saipan， SC8180X， SDM429W， SDX55， SM8150， SM8250， SXR2130
　　0x06 CVE-2020-3700（unknown）
　　发生位置：
　　wnm_ap.c的ieee802_11_rx_w***eep_req（）
　　补丁：
　　触发方法：
　　需要一个AP （无线网接入点），伪造client，client向AP请求WNM-Sleep模式请求，且传输的数据包总大需要小于IEEE80211_HDRLEN+3。
　　漏洞成因：
　　len《1时，pos+1将会无效，但是dialog_token = *pos++会导致pos后的8位无论如何都会被读取来作为对话框令牌。
　　修复方法：
　　增加对len的判断，摒弃len小于1的WNM-Sleep请求。
　　时间：
　　是什么：
　　高通WLAN模组，该函数主要用来处理wifi的WNM-Sleep模式请求
　　影响设备：
　　APQ8053， APQ8096AU， IPQ4019， IPQ8064， IPQ8074， MDM9607， MSM8909W， MSM8996AU， QCA6574AU， QCA9531， QCA9558， QCA9980， SC8180X， SDM439， SDX55， SM8150， SM8250， SXR2130
　　0x07 CVE-2019-14037（unknown）
　　发生位置：
　　sockev_nlmcast.c的sockev_client_cb（）
　　补丁：
　　触发方法：
　　在sockev_client_cb（）函数进行socket-》sock进行空指针检查之后，socket-》sock-》所需字段进行使用之前，尝试用race condition来关闭socket，如果正好是最后一次引用，就可以触发UAF。
　　漏洞成因：
　　在使用sock字段的参数时，使用了socket-》sock-》所需字段，如果此时socket被关闭，会导致null指针解引用错误，可能会造成UAF。
　　修复方法：
　　增加sk来存储sock结构，避免使用socket-》sock-》所需字段，直接使用sock-》所需字段。
　　时间：
　　是什么：
　　netlink内核通信，漏洞函数主要是进行了netlink消息的转存工作。
　　影响设备：
　　APQ8009， APQ8053， APQ8096AU， APQ8098， MDM9206， MDM9207C， MDM9607， MDM9640， MDM9650， MSM8905， MSM8909W， MSM8996， MSM8996AU， QCN7605， QCN7606， QCS605， SC8180X， SDA660， SDA845， SDM439， SDM630， SDM636， SDM660， SDM670， SDM710， SDM845， SDX20， SDX24， SDX55， SM8150， SXR1130
　　0x08 CVE-2019-14099（unknown）
　　发生位置：
　　相机驱动的多个函数都受到了影响，但是都是忘记增加检测函数了。
　　补丁：
　　https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/？id=8ce459a901ffa7a8950e164c0bccb9e956f8f7f3
　　https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/？id=b3af813578c1bbda73f01e776498853deb445fd0
　　https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/？id=c8995022daf5cd3cc0c90a75a73f658ab05182d4
　　https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/？id=21fbc0b4ac1a5009060a6f79fc107182b9b15645
　　https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/？id=ee26a0afac0e506284822c0994f1ae40f0ab5021
　　触发方法：
　　以cam_virtual_cdm_submit_bl这个函数的补丁为例。主要需要伪造的数据结构为cam_cdm_hw_intf_cmd_submit_bl，如果cdm接口的命令长度（len）+偏移（offset）大于系统给的缓冲区就会出现越界拷贝，但是这个缓冲区是系统分配的，我们可以控制的参数只有一个buf_handle不可控的，所以应该无法很好的触发漏洞。
　　漏洞成因：
　　这里以cam_virtual_cdm_submit_bl这个函数的补丁为例。从cpu获取到缓冲区大小len，没有进行大小判断，可能会导致该缓冲区大小小于当前指令（cdm_cmd）的长度，导致越界写，当前的所有指令长度（cdm_cmd）和数量都是从用户空间取得的。
　　修复方法：
　　所有的补丁都差球不多，以cam_virtual_cdm_submit_bl这个函数的补丁为例。增加对len长度的判断，如果长度不够，直接退出。
　　时间：
　　是什么：
　　高通相机相关的一堆驱动都有相同的错误，我上诉分析的一个漏洞点是高通相机硬件相关的高速缓存驱动（MSM Camera HW CDM driver）。
　　影响设备：
　　APQ8053， MDM9206， MDM9207C， MDM9607， MSM8909W， MSM8917， MSM8953， Nicobar， QCM2150， QCS405， QCS605， QM215， Saipan， SC8180X， SDA845， SDM429， SDM429W， SDM439， SDM450， SDM632， SDX24， SDX55， SM6150， SM7150， SM8150， SM8250， SXR1130， SXR2130
　　0x09 CVE-2019-14100（unknown）
　　发生位置：
　　npu_debugfs.c的npu_debug_reg_write（）
　　补丁：
　　触发方法：
　　首先需要开启内核的debugfs，Kernelhacking —》Debug Filesystem。然后按照debugfs的步骤依次建立文件，最后直接定义的是npu_reg_fops ，然后即可直接调用.write向npu的硬件寄存器写入任意内容。
　　漏洞成因：
　　在debugfs中加入了写函数，但是当前的函数是用来进行npu的reg（注册表信息操作的）的debugfs操作，会导致用户在使用debugfs时修改npu的硬件寄存器，其中修改的数值是从用户空间拷贝得到的但是具体我不明白为什么禁止debugfs时禁止修改寄存器的值，从高通的漏洞说明来看这个是一种规定。
　　修复方法：
　　删除了npu_debug_reg_write（）函数，禁止了debugfs时对硬件寄存器的修改。
　　时间：
　　是什么：
　　QTI传感器芯片神经中枢处理单元模块（加速神经网络处理），主要是debugfs时的reg_write（）
　　影响设备：
　　MDM9206， MDM9207C， MDM9607， Nicobar， QCS405， SA6155P， SC8180X， SDX55， SM8150