具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”、“第四”等仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

实施例一

参见图1、2、3、4，本实施例提供了分析源库模式缺陷检测器的深层结构体指针分析优化方法，包括以下步骤：

步骤一

先根据Source-Sink判定构建source摘要和sink摘要，source摘要和sink摘要内容一致，以source摘要为例，source摘要部分直接获取source所在函数函数名、涉及的核心变量名称，再结合绑定分析和别名分析收集函数名、核心变量名的别名及其所在位置，然后分别根据source摘要和sink摘要，通过直接函数调用分析、函数指针分析和相似深层结构体分析的方式寻找关联函数，每种方式收集的关联函数的置信度有所不同，然后汇总各个方式收集的关联函数，并进行后续分析；

其中，直接函数调用分析：直接通过函数调用图，收集source节点和sink节点的调用关系与被调用关系，该直接函数调用分析方法收集的结果置信度随调用函数深度逐渐减低；

函数指针分析：根据source函数和sink函数的函数名的绑定分析与别名分析结果，收集涉及的函数指针及其调用位置，补充入直接函数调用分析中，若函数指针涉及深层结构体，则有限度的采用相似深层结构体分析进行展开，该部分分析的置信度除考虑调用函数深度外，还额外考虑别名分析的精度；

相似深层结构体分析：对source函数和sink函数涉及的核心变量进行别名分析，若涉及深层结构体，则对深层结构体建立摘要，并通过抽象语法树由深到浅收集同名深层结构体可能涉及的代码段，通过抽象语法树由深到浅收集的结果需考虑同名深层结构体出现次数与目标代码段与source-sink节点上下文相关性；

置信度与结构体层次深度和在代码中出现频率有关，实际测试中，若被测代码风格经过静态代码分析工具充分测试，代码风格较好，则本处置信度极高，能引入大量传统静态代码分析难以直接分析的复杂代码逻辑关系；

步骤二

在函数调用图上分析收集的关联函数，得到包括source节点、sink点和全部关联函数的函数调用图的子图；

步骤三

对子图中任意相邻两点m和n，采用Source-Sink技术进行分析，得到若干分段source-sink可达性判定结果，可达性判定可复用原Source-Sink分析和过滤函数，也可独立编写，若相邻两点的Source-Sink判定为复杂度过高的不可判定问题，则单独标记两点，并根据相邻两点的置信度评分排序供后续人工审计使用；

步骤四

对分段结果进行交操作和并操作汇总，最终得到source-sink整体判定条件，实现深层结构体指针分析优化。

对图3的分析结果如图4所示，图中最终source到sink的条件为(f(source, n1)&& f(m1, m2)) || (f(source, n1) && f(m1, m2))。

实施例二

根据CVE-2021-29649描述，分析linux-5.11.1版本的内核代码，该CVE例子有明确的Source-Sink定义，关联关系较为复杂，根据CVE描述和git修改记录，本处缺陷为实际内存泄漏发生后由开发人员修正，非静态分析工具扫描后修正，根据本发明对CVE-2021-29649实施如下分析：

1.在linux-5.11.1\kernel\usermode_driver.c中找到成对的source-sink定义【umd_info->tgid = get_pid(task_tgid(current));】和【put_pid(umd_info->tgid);】；

2.对umd_info的Source-Sink进行关联，发现该处同时涉及全局变量、深层指针和多级函数指针调用，难以进行直接数据流关联；

3.对Source函数umd_setup进行分析:

3.1.通过函数调用图直接分析Source的被调用点，发现为空；

3.2.通过抽象语法树分析Source通过函数指针传递的语句，发现有且仅有一处关联函数fork_usermode_driver；

3.2.1.分析调用点call_usermodehelper_setup，Source函数指针通过参数init传入，在sub_info->init=init唯一进行赋值，对函数指针可建立结构体摘要[subprocess_info]->init；

3.2.2.通过抽象语法树层次搜索[subprocess_info]->init字段的调用，可得到[subprocess_info]->init字段有且仅有一处关联函数call_usermodehelper_exec_async；

4.对Sink函数umd_cleanup进行分析:

4.1.通过函数调用图直接分析Sink的被调用点，发现为空；

4.2.通过抽象语法树分析Sink通过函数指针传递的语句，发现有且仅有一处关联函数fork_usermode_driver；

4.2.1.分析调用点call_usermodehelper_setup，Source函数指针通过参数init传入，在sub_info->cleanup=cleanup唯一进行赋值，对函数指针可建立结构体摘要[subprocess_info]->cleanup；

4.2.2.通过抽象语法树层次搜索[subprocess_info]->cleanup字段的调用，可得到[subprocess_info]->cleanup字段有且仅有一处关联函数call_usermodehelper_exec_async，对其进行进行分析可知存在调用链 call_usermodehelper_setup() --> call_usermodehelper_exec_work() --> call_usermodehelper_exec_async() -->[subprocess_info]->cleanup()；

5.通过Source-Sink结构体摘要分析：

5.1.通过函数内分析可知tgid的上层结构体umd_info唯一来自subprocess_info类型info的data字段，建立结构体摘要[subprocess_info]->data->tgid；

5.2.通过函数内分析可知tgid的上层结构体umd_info唯一来自subprocess_info类型info的data字段，建立结构体摘要[subprocess_info]->data->tgid，与5.1结构体摘要相同，判定有强置信度；

5.3.通过抽象语法树层次分别搜索[subprocess_info] ->data->tgid；[subprocess_info]->data字段的赋值/被赋值调用，可得到[subprocess_info] ->data->tgid无直接匹配，[subprocess_info]->data字段仅有一处关联函数call_usermodehelper_setup；

6.综合上述关联函数，可得到Source-Sink的各项可能调用链，以此为前提辅助对Source-Sink进行分段分析。最终需要分析：

6.1.call_usermodehelper_exec函数内info->work到call_usermodehelper_freeinfo的可达性f1；

6.2.info->work到sourceNode的调用链可达性f2；

6.3.call_usermodehelper_freeinfo到sinkNode的可达性f3。

最终计算f1&&f2&&f3即为本处是否存在内存泄漏的判定。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。