Kernel memory vulnerability cause diagnosis method based on causal chain analysis

Abstract

The invention belongs to the field of kernel vulnerability analysis of operating systems, and particularly relates to a kernel memory vulnerability cause diagnosis method based on causal chain analysis. The method comprises the steps of restoring a data dependency graph and a function call tree in a vulnerability triggering process from instruction-level tracking data in the vulnerability triggering process, and restoring a kernel execution state and kernel behavior semantics in combination with function modeling; analyzing the kernel execution state, and identifying an abnormal execution behavior in the kernel memory vulnerability in combination with the abnormal model of the kernel memory vulnerability; based on causal chain analysis of dynamic programming, causes of vulnerabilities are analyzed and obtained in a series of kernel execution abnormal behaviors. According to the method, the kernel execution state and behavior semantics are restored, the kernel abnormal behavior state is identified, and the causal chain of the abnormal behavior is analyzed, so that the cause of the kernel memory vulnerability can be effectively diagnosed, and the subsequent vulnerability repair work is promoted.

Description

Technical Field

[0001] This invention belongs to the field of operating system kernel vulnerability analysis technology, specifically, it relates to a method for diagnosing the causes of kernel memory vulnerabilities based on causal chain analysis. Background Technology

[0002] With the widespread application of automated operating system kernel vulnerability discovery technologies, the number of reported kernel vulnerabilities has shown a significant upward trend. Kernel memory vulnerabilities are the most numerous and harmful type of security vulnerability. To effectively mitigate the threat of kernel memory vulnerabilities, security experts need to analyze the causes of vulnerabilities and develop remediation plans as soon as possible. However, manual kernel vulnerability cause analysis is difficult to conduct on a large scale. On the one hand, kernel vulnerability cause analysis requires a high level of knowledge and skills from analysts, and there are few analysts capable of performing this task. On the other hand, due to the complex business logic and massive code size of the kernel, manual kernel vulnerability cause analysis is extremely inefficient. Analysts often need to spend a lot of time starting from the vulnerability crash logs, combining them with the kernel source code, sorting out the control flow and data flow of the vulnerability triggering process, and gradually understanding the logic of the vulnerability occurrence. These two difficulties cause the speed of kernel vulnerability analysis and remediation to lag far behind the growth rate of kernel vulnerability reports, exposing the operating system kernel to significant security risks. Therefore, there is an urgent need for an efficient automated method to diagnose the causes of kernel vulnerabilities in order to promote the remediation of kernel vulnerabilities.

[0003] Existing automated vulnerability cause diagnosis methods fall into three categories. The first category is vulnerability cause diagnosis methods based on differential analysis. These methods determine the possible causes of vulnerabilities by comparing the differences between program behavior when a large number of vulnerabilities are triggered and the program behavior when the program is running normally. This analysis method is relatively automated; however, it is not applicable to the kernel. This is because this method requires obtaining a large number of similar but different vulnerability proof-of-concept inputs to trigger the vulnerable program behavior, as well as normal program inputs similar to these vulnerability proof-of-concept inputs for comparison with the vulnerable behavior. Kernel vulnerabilities typically only include one vulnerability proof-of-concept program when reported, making it difficult to obtain a large number of high-quality similar vulnerability proof-of-concept programs, thus making it difficult to use differential analysis for vulnerability cause diagnosis.

[0004] The second category is vulnerability diagnosis methods based on hypothesis testing. This type of method replays the vulnerability triggering process, hypothesizes that certain steps lead to the vulnerability, and then uses forced execution to change the corresponding execution path and continue execution, observing whether the vulnerability still triggers. If the vulnerability disappears, it indicates that the code or path constraints on the path corresponding to those steps may be the true cause of the vulnerability. Although this type of method can diagnose using only a single vulnerability concept verification input, its hypothesis testing technique requires complete control over the entire execution process of the target program to force the execution of a certain hypothetical path to verify the vulnerability's cause. Currently, for the kernel, complete control over its execution is quite difficult. The kernel contains a large number of concurrent processes with complex interactions, making it difficult to simultaneously control all processes to execute in a predetermined manner.

[0005] The third type of method is vulnerability cause diagnosis based on vulnerability introduction submission. This method uses a vulnerability proof-of-concept program to perform a binary search in the commit history of the target software repository. If the vulnerability is triggered on an intermediate version, it means the vulnerability introduction submission must have been made before that version; if the vulnerability is not triggered, it means the vulnerability introduction submission was made after that version. By continuously narrowing down the commit history interval through binary search, the code submission introducing the vulnerability is eventually located. However, this method has low accuracy for three reasons: First, due to the logic of certain specific software versions, some vulnerability proof-of-concept programs can only trigger vulnerabilities on specific software versions and cannot trigger them on other versions where the vulnerability exists, causing a mismatch between test results and vulnerability existence; second, the triggering process of some vulnerabilities is not stable enough, making it impossible to obtain reliable vulnerability existence test results; third, some vulnerability proof-of-concept programs can trigger multiple vulnerabilities, possibly triggering other unrelated vulnerabilities on versions where the target vulnerability does not exist, also causing misjudgments of vulnerability existence. Therefore, this method is difficult to accurately locate vulnerability introduction submissions in the real world.

[0006] In summary, existing methods for diagnosing the causes of vulnerabilities have significant limitations in terms of applicability and accuracy, making them ineffective in addressing real-world kernel memory vulnerability diagnosis. Therefore, a new method is needed to improve the robustness and accuracy of kernel memory vulnerability diagnosis, thereby better facilitating the analysis and remediation of kernel memory vulnerabilities and ensuring the security of the operating system kernel. Summary of the Invention

[0007] The purpose of this invention is to provide a method for diagnosing the causes of kernel memory vulnerabilities based on causal chain analysis, so as to overcome the shortcomings of existing technologies in diagnosing the causes of kernel memory vulnerabilities.

[0008] This invention effectively diagnoses the causes of kernel memory vulnerabilities by reconstructing the kernel execution state and behavioral semantics, identifying abnormal kernel behavior states, and analyzing the causal chains of these abnormal behaviors. Specifically, this invention first reconstructs the data dependency graph and function call tree from the instruction-level trace data of the vulnerability triggering process, and combines this with function modeling to reconstruct the kernel execution state and kernel behavioral semantics. Then, it analyzes the kernel execution state, combining this with anomaly models of kernel memory vulnerabilities to identify abnormal execution behaviors. Finally, it employs dynamic programming causal chain analysis to analyze the causes of the vulnerability from a series of abnormal kernel execution behaviors.

[0009] The following section defines kernel memory vulnerabilities, their causes, and causal chains: Kernel memory vulnerabilities are security flaws caused by improper kernel memory operations (such as out-of-bounds access, use after freeing, or use without initialization), which may be exploited by attackers to achieve privilege escalation or gain control of the kernel.

[0010] The cause of the vulnerability, the root cause of the kernel memory vulnerability, in this invention refers to the root abnormal behavior and its code and instructions that produce a series of abnormal behaviors.

[0011] A causal chain includes a series of abnormal kernel behaviors, their code and instructions related to the occurrence of a kernel memory vulnerability, and the causal relationships between them.

[0012] This invention provides a method for diagnosing the causes of kernel memory vulnerabilities based on causal chain analysis, the specific steps of which are as follows: (1) Execution state and semantic reconstruction: The data dependency graph and call tree in the vulnerability triggering process are reconstructed from the original instruction-level trace data in the vulnerability triggering process. Combined with function modeling, the kernel execution state and kernel behavior semantics are reconstructed in a structured way. Among them, the call tree is the tree formed by the function call process in the vulnerability triggering process, and the data dependency graph is the graph formed by the data dependency relationship generated by the kernel execution in the vulnerability triggering process. (2) Abnormal behavior identification: Based on the restored kernel execution state and behavioral semantics, combined with the kernel memory vulnerability anomaly model, the abnormal behaviors generated during the kernel vulnerability triggering process are identified, and a set of abnormal behaviors is obtained. Each abnormal behavior contains the corresponding behavior type and related data nodes in the data dependency graph. Abnormal behaviors include memory access space anomalies, memory access time anomalies and memory access semantic anomalies. (3) Causal chain analysis: Based on the identified abnormal behaviors, and according to the relationship between these abnormal behaviors and vulnerability triggering, a dynamic programming method is used to construct the causal chain of abnormal behaviors, thereby locating the true cause of the vulnerability.

[0013] In this invention, in step (1), the call tree is a tree-shaped data structure. The nodes in the call tree represent the stack frame of a function call, the edges between the nodes represent the function call relationship, the parent node on the edge is the caller, the child node is the callee, and the root node of the tree is a virtual node, representing the user-mode main function of the vulnerability proof-of-concept program. Based on the call tree, the complete call stack at any time of kernel execution can be restored by traversing the parent node of any node.

[0014] In this invention, in step (1), the data dependency graph is a directed acyclic graph. Nodes in the data dependency graph represent possible operands of an instruction, and record the specific value, data size, data generation timestamp, and semantic label information of the operand at that node. Each node in the data dependency graph uniquely corresponds to a node in the call tree, representing the stack frame where the kernel execution occurred when the data node was generated. The edges in the graph represent the input-output dependencies between these operands. Semantic labels are obtained based on the way the operands are generated, and their types include temporary values, constants, memory addresses, memory allocation addresses, memory release addresses, memory reads, memory writes, register reads, register writes, and unknowns.

[0015] In this invention, in step (1), the semantics of memory management behavior are restored by the method of memory management function identification: when the memory management function call instruction is identified in the original trace data, the data node involved in the instruction actually executed by the corresponding memory management function is deleted in the data dependency graph and replaced with a unified function call entry. The operands of the function call entry include function parameters and function return values. The data dependency relationship involved is obtained according to the data dependency relationship of the original instruction. The corresponding call tree node is set as the call tree node corresponding to the function call instruction. At the same time, the semantic label of the corresponding operand node is modified according to the specific function function.

[0016] In this invention, in step (2), the fine-grained classification of access space anomalies in the kernel memory vulnerability anomaly model includes accessing invalid base addresses, buffer overflow, accessing invalid code addresses, misusing error codes as addresses, and misusing integer overflows as addresses; The fine-grained classification of access timing anomalies mainly includes two categories: use before initialization and use after release.

[0017] In this invention, access semantic exceptions include type confusion, which means that a value in memory is incorrectly used as another type different from its original type, and the original type cannot be converted to the used type.

[0018] In this invention, when accessing semantic anomaly identification, a type grid is constructed. The kernel implements data structure inheritance through nested structures. If the first member of a structure is also a structure, then the structure can be converted to the type of its first member. The partial order relationship between the structure type and the first member type is added to the type grid. If two types have a partial order relationship in the type grid, they can be converted to each other.

[0019] In this invention, step (3), the causal chain analysis specifically includes: The causal analysis problem is modeled as a path search problem: finding the path from any anomalous behavior trigger in the data dependency graph that leads to the vulnerability trigger point and contains the maximum number of anomalous behaviors; all instructions involved in this path and the anomalous behaviors they trigger are called a causal chain, with the first anomalous behavior being the cause and the subsequent anomalous behavior being the effect; the instructions on the causal chain represent an anomalous behavior or an intermediate step in the causal relationship of anomalous behavior, and the source anomalous behavior of the causal chain is the analyzed cause of the vulnerability.

[0020] In this invention, the causal chain is solved using a dynamic programming algorithm, as follows: The state count(u) of the dynamic programming algorithm is defined as the number of anomalous behaviors among all paths ending at node u in the data dependency graph. Since the data dependency graph is directed acyclic, this dynamic programming state is iteratively updated using the following equation:

[0021] Here, v represents the direct predecessor node of node u in the data dependency graph, count(v) is the final number of abnormal behaviors in all paths ending at node v, and UB(v) represents the number of abnormal behaviors represented by node v itself. By repeatedly traversing the nodes and edges in the data dependency graph and updating the count value of each node until the maximum value of count(crash) is found, the path of the causal chain is found, where crash represents the data node that directly caused the vulnerability to be triggered; By traversing backwards from the crash node along the update path of count, we can find all the nodes in the path containing the most abnormal behavior, as well as the instructions and abnormal behaviors corresponding to these nodes, and construct the final causal chain.

[0022] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention provides a kernel memory vulnerability cause diagnosis method based on causal chain analysis. By comprehensively utilizing the features of security indicators, positive sample variants, and hard negative samples in patch messages, it achieves high-precision identification of hidden security patches. This method not only resists the complexity of code changes and data imbalance issues but also automates the processing of large numbers of patch messages, reducing manual intervention and significantly improving the accuracy and efficiency of hidden patch location. Through these innovations, this invention provides security analysts with a more accurate and efficient solution for hidden patch location, effectively improving software security. Attached Figure Description

[0023] Figure 1 This is a diagram illustrating the overall framework of a kernel memory vulnerability diagnosis method based on causal chain analysis.

[0024] Figure 2 This is a diagram illustrating the process of constructing a tree.

[0025] Figure 3 This is a schematic diagram illustrating the process of constructing a data dependency graph.

[0026] Figure 4 This is a schematic diagram of the causal chain analysis process.

[0027] Figure 5 This is a diagnostic report on the cause of a real kernel vulnerability. Detailed Implementation

[0028] The present invention will be further described below with reference to the embodiments and accompanying drawings.

[0029] This invention primarily focuses on diagnosing the causes of kernel memory vulnerabilities, aiming to pinpoint the root cause by analyzing instruction-level tracing data during the kernel memory vulnerability triggering process. The overall framework of this invention is shown in the diagram below. Figure 1 As shown. It includes: an execution state and semantic reconstruction module, an abnormal behavior identification module, and a causal chain analysis module. The execution flow of this invention is as follows: (1) Execution State and Semantic Reconstruction Module: Reconstructs the data dependency graph and call tree during the vulnerability triggering process from the original instruction-level tracing data. The data dependency graph and call tree reflect the kernel execution state during the vulnerability triggering process from different perspectives. This part of the state only includes the program state, so it is necessary to further reconstruct the behavioral semantics during kernel execution, such as memory management behavior, based on function modeling; (2) Abnormal behavior identification module: Based on the restored kernel execution state and behavioral semantics, combined with the kernel memory vulnerability anomaly model, the module identifies abnormal behaviors generated during the kernel vulnerability triggering process, such as memory access space anomaly, memory access time anomaly, memory access semantic anomaly, etc. These anomalies may be important factors in the cause of the vulnerability. (3) Causal chain analysis module: Based on the identified abnormal behaviors, according to the relationship between these abnormal behaviors and vulnerability triggering, the dynamic programming method is used to construct the causal chain of abnormal behaviors, thereby locating the true cause of the vulnerability.

[0030] The following is a further description of each module: 1. Execution Status and Semantic Reconstruction Module Because the instruction-level trace data collected during the vulnerability triggering process is linear and lacks necessary structure and semantics, it is difficult to directly apply it to vulnerability cause diagnosis. Therefore, the execution state and semantic restoration module is responsible for structuring this data and supplementing it with the necessary semantics required for cause analysis. This module takes the instruction-level trace data during the vulnerability triggering process as input, outputs a data dependency graph and call tree representing the kernel execution state, and restores the important behavioral semantics of the kernel during the vulnerability triggering process, such as memory management semantics.

[0031] (1) Execution state restoration Because raw instruction-level vulnerability trigger trace data lacks structure and semantics, it is difficult to directly apply it to vulnerability cause analysis. This raw trace data needs to be processed to describe the kernel execution state in a structured way before it can be used for cause analysis.

[0032] The kernel execution state includes a tree formed by function calls during vulnerability triggering, called the call tree; and a graph formed by data dependencies generated during kernel execution during vulnerability triggering, called the data dependency graph.

[0033] A call tree is a tree-like data structure. Nodes in a call tree represent stack frames of a function call. Edges between nodes represent function call relationships, with the parent node of an edge being the caller and the child node being the callee. The root node of the tree is a virtual node representing the user-space main function of the vulnerability proof-of-concept program. Based on the call tree, the complete call stack at any given time can be reconstructed by traversing the parent nodes of any node.

[0034] Calling the tree construction method as follows Figure 2 As shown. First, a root node is created, and the current stack frame is set as this root node. The root node and the stack frame it represents have no practical meaning; they are only used as markers. Then, all instructions executed during the vulnerability triggering process are scanned in execution order. If a call instruction is encountered, a new tree node is created to represent the callee's stack frame, and an edge is drawn between the tree node representing the current stack frame and the newly created tree node. Then, the current stack frame is set as the newly created tree node. If a return instruction is encountered, the current stack frame is set as the parent node of the current stack frame. After scanning all instructions, the call tree is completed.

[0035] A data dependency graph is a directed acyclic graph (DAG). Nodes in the graph represent potential operands of an instruction, such as registers or memory locations, and edges represent the input-output dependencies between these operands. An instruction's output operands depend on its input operands, which in turn may depend on the output operands of other instructions. Nodes also record information such as the specific value of the operand, its size, timestamp of creation, and semantic labels for further analysis. Semantic labels are derived from how the operand was created and include types such as temporary values, constants, memory addresses, memory allocation addresses, memory deallocation addresses, memory reads, memory writes, register reads, register writes, and unknown. Furthermore, each node in the data dependency graph uniquely corresponds to a node in the call tree, representing the stack frame in which the kernel execution occurred when that data node was created.

[0036] The method for constructing a data dependency graph is as follows: Figure 3 As shown. Assume the vulnerability triggering process trace contains two instructions: "movrbp,rdi" and "mov [rbp], rsi". First, according to the semantics of the first instruction, this instruction reads the value from register rdi. Therefore, a node labeled "Register Read" is constructed in the data dependency graph, representing the value of register rdi, with a value of 0x10. The instruction writes the value from rdi to rbp, so a node labeled "Register Write" is created, representing the value of the rbp register, with a value of 0x10. Since the value of rbp comes from rdi, an edge is connected between these two data nodes to indicate a data dependency. Similarly, for the second instruction, it first reads the values ​​of the rbp and rsi registers, creating two data nodes to represent the corresponding reads. Then, the instruction writes the value of rsi to the memory pointed to by rbp. Since the value of rbp is 0x10, a data node labeled "Memory Write" is created, representing the memory address 0x10. Because this memory write operation depends on both the write address rbp and the write value rsi, two data dependency edges are created in the data dependency graph, with the "Memory Write" node pointing to the two "Register Read" nodes respectively.

[0037] (2) Perform semantic reduction In addition to restoring the kernel execution state, this invention further restores some kernel behavioral semantics, particularly those related to memory management, such as memory allocation and deallocation. The kernel manages these memory management behaviors in a unified manner; therefore, this invention uses a memory management function identification method to restore these memory management behavioral semantics. When a memory management function call instruction is identified in the original trace data, the data nodes involved in the actual execution instructions of the corresponding memory management function are deleted from the data dependency graph and replaced with a unified function call entry point. The operands of the function call entry point include function parameters and function return values, and their data dependencies are obtained based on the data dependencies of the original instructions; the corresponding call tree node is set to the call tree node corresponding to the function call instruction. Simultaneously, the semantic labels of the corresponding operand nodes are modified according to the specific function function; for example, the return value of a memory allocation function will be assigned a memory allocation address label, the parameters of a memory deallocation function will be assigned a memory deallocation address label, and so on. For memory allocation behavior, the size of the allocated memory will also be identified and recorded from the original trace data.

[0038] 2. Abnormal Behavior Detection Module Vulnerabilities are typically triggered by a series of abnormal behaviors caused by the vulnerability's underlying cause. To analyze the cause of a vulnerability, it's essential to first identify the abnormal kernel execution behaviors that occur during the vulnerability triggering process. These abnormal behaviors violate kernel memory access rules, thus causing errors or vulnerabilities. This invention models the abnormal behaviors that may exist during the occurrence of classic kernel memory vulnerabilities. This modeling allows for the identification of abnormal behaviors by combining structured data obtained from execution state and semantic reconstruction. The module's input includes: a kernel memory vulnerability anomaly model, a data dependency graph, a call tree, and kernel behavior semantics. The module outputs a set of abnormal behaviors, each containing a corresponding behavior type and related data nodes in the data dependency graph.

[0039] (1) Kernel memory vulnerability anomaly model In the kernel, memory vulnerabilities are typically caused by three main categories of exceptions: access space exceptions, access timing exceptions, and access semantic exceptions. This invention defines finer-grained exception types for each of these three main categories, used for identifying abnormal behavior during kernel execution.

[0040] The Access Space Exception model states that, in most cases, the kernel should only execute kernel space instructions and access kernel space addresses. For each memory access and indirect branch jump, if the accessed address is not a valid kernel address, an Access Space Exception occurs. Fine-grained classifications of Access Space Exceptions include invalid base address access, buffer overflow, invalid code address access, misuse of error code as address, and integer overflow misuse of address. Invalid base address access refers to a memory access where the base address is not a valid kernel space memory address; buffer overflow refers to a memory access where the offset exceeds the valid range of the memory buffer; invalid code address access refers to an indirect branch jump where the target is not a valid kernel code segment address; misuse of error code as address refers to a function that expects to return a memory address actually returning an error code, and this error code is used directly as a memory address without checking; and integer overflow misuse of address refers to an overflowing integer that, while conforming to the format of a memory address, is incorrectly used as a memory address.

[0041] The access timing exception model states that dynamically allocated memory regions can only be accessed within their lifetime, from allocation to deallocation, and the allocated memory region should be initialized before use. If a memory access occurs outside its lifetime, it is considered an access timing exception. Fine-grained classifications of access timing exceptions mainly include two categories: uninitialized use and post-deallocation use. Uninitialized use refers to reading and using values ​​from allocated memory without proper initialization. Post-deallocation use refers to writing to or reading from memory even after it has been freed.

[0042] The access semantic exception model defines access semantic exceptions as those caused by the inappropriate use of memory content. This invention primarily considers type confusion as a type of access semantic exception. Type confusion refers to the situation where a value in memory is incorrectly used as a different type than its original type, and the original type cannot be converted to the used type. Incorrect use of data types can lead to subsequent behavioral anomalies such as misjudging the size of data types and misusing non-pointer data as pointers.

[0043] (2) Abnormal behavior identification based on anomaly model Combining the kernel execution state reconstructed in step (1), including the data dependency graph, call tree, and behavioral semantics, the kernel memory vulnerability anomaly model can be used to identify abnormal kernel execution behavior during vulnerability triggering, and the identified abnormal behaviors can be constructed into an anomaly behavior set. The identification methods for the above three types of anomalies are as follows: The method for identifying access space exceptions is as follows: If the specific value of a data node with the semantic label "memory address" in the data dependency graph is not a valid kernel space address, then the instruction corresponding to that value node is considered to have triggered an access space exception, and the data node is marked as an invalid base address exception. If the address source of the data node is memory allocation, then the memory size allocated from the memory allocation behavior semantics is considered. If the actual access address exceeds this size, the data node is marked as a buffer overflow exception. If the data node corresponds to an indirect branch instruction, it is determined to be an invalid code address access exception. By further examining its numerical characteristics and source, two types of exceptions can be distinguished: misuse of error code as address and misuse of integer overflow as address. If the value comes from the return value of another function and its size is between -1024 and -1, then the data node has generated an error code misuse as address exception; if the value comes from the signed extension of a negative number, then the data node has generated an integer overflow misuse as address. Of all the above cases, the only exception is in kernel I / O functions such as `copy_from_user` and `copy_to_user`. Accessing non-kernel memory addresses is not considered a space access exception because the kernel requires these functions to ensure legitimate access to user space addresses.

[0044] The method for identifying access timing anomalies is as follows: To identify uninitialized memory before use, this invention checks all nodes tagged with "Memory Read". If its address originates from memory allocation, the access target of this node belongs to heap memory. If there is no corresponding "Memory Write" node before the "Memory Read" node, it indicates that the data node has generated an uninitialized heap memory access anomaly. If its address originates from a stack register, the access target of this node belongs to stack memory. If there is no corresponding "Memory Write" node before the "Memory Read" node, or the write target of the "Memory Write" node is not located on the valid stack frame of the "Memory Read" node and any of its callers, it indicates that the data node has generated an uninitialized stack memory access anomaly. To identify use after deallocation, if a "Memory Release Address" node and a "Memory Address" node have the same origin in the data dependency graph, and the timestamp of the "Memory Address" node is later than that of the "Memory Release Address" node and is used as the address of a "Memory Read" node or a "Memory Write" node, then the "Memory Read" or "Memory Write" address has generated a use after deallocation anomaly.

[0045] The method for identifying semantic anomalies is as follows: To identify type confusion, this invention infers the data type of data nodes in the data dependency graph after construction. For nodes labeled "register read," their type can be directly retrieved from the debug information. For "memory read" and "memory write" nodes, the data type can be retrieved from the debug information by resolving the base address register and offset of the memory access. Due to compiler optimizations, the type information for some registers and memory may be incomplete. In this case, this invention infers the missing data type through type propagation: for value nodes with known types, the missing data type is recursively inferred forward and backward along the edges in the data dependency graph. To check the convertibility between different data types, this invention constructs a type lattice. The kernel implements data structure inheritance through nested structures. If the first member of a structure is also a structure, then the structure can be converted to the type of its first member. We add the partial order relation between the structure type and the first member type to the type lattice. If two types have a partial order relation in the type lattice, they can be converted to each other. Furthermore, all basic types are considered to be convertible to each other. If the types of a pair of "memory read" and "memory write" data nodes are not convertible to each other, it means that these two data nodes have caused a type confusion exception.

[0046] 3. Causal Chain Analysis Module This module takes the set of abnormal behaviors output by the abnormal behavior identification module as input, analyzes the causal relationship between abnormal behaviors, derives the causal chain, thereby locating the true cause of the vulnerability, and compiles it into a vulnerability cause report, which is the final output of this invention.

[0047] This module models the causal analysis problem as a path search problem: finding the path from any anomalous behavior trigger in the data dependency graph that leads to the vulnerability trigger point and contains the maximum number of anomalous behaviors. All instructions involved in this path and the anomalous behaviors they trigger are called a causal chain, with the first triggered anomalous behavior being the cause and the subsequent triggered anomalous behavior being the effect. Instructions in the causal chain either represent an anomalous behavior or are intermediate steps in the causal relationship between anomalous behaviors. The source anomalous behavior in the causal chain is the analyzed vulnerability cause.

[0048] To solve causal chains, this invention designs a dynamic programming algorithm. The state count(u) of the dynamic programming algorithm is defined as the number of anomalous behaviors among all paths ending at node u in the data dependency graph. Since the data dependency graph possesses the property of being directed acyclic, this dynamic programming state can be iteratively updated using the following equation:

[0049] Once the maximum value of `count(crash)` is found, the path of the causal chain is located. Here, `crash` represents the data node that directly caused the vulnerability to be triggered, which can be analyzed from the vulnerability crash report. Finally, by traversing backwards from the `crash` node along the update path of `count`, all nodes in the path containing the most abnormal behavior, as well as the corresponding instructions and abnormal behaviors of these nodes, can be found, thus constructing the final causal chain and identifying the cause of the vulnerability.

[0050] The process of solving the causal chain is as follows: Figure 4 As shown in the diagram. For ease of understanding, the edges in the data dependency graph are marked in reverse order, indicating the direction of data propagation during the vulnerability triggering process. Three nodes containing anomalous behavior were detected in the data dependency graph: nodes 1, 4, and 7, with node 7 being the vulnerability triggering node. The dynamic programming algorithm iteratively updates the count value of each node, eventually converging to the value marked in the graph. Based on the increasing relationship of the count values, a path containing the most anomalous behavior can be found: 1->2->4->6->7. This path is the causal chain. Since the anomalous behavior of node 1 ultimately led to the anomalous behavior of nodes 4 and 7, the anomalous behavior of node 1 is the true cause of the vulnerability.

[0051] The final analysis report is as follows: Figure 5 As shown in the diagram, the "RootCauseChain" section illustrates the causal chain of the cause analysis. The causal chain shows that the vulnerability was caused by type confusion, which in turn led to two abnormal behaviors: out-of-bounds access and invalid base address, ultimately causing a kernel crash. The first half of the analysis report details the involved instructions, call tree, and data dependencies, with data dependencies related to the causal chain highlighted in color.

[0052] Real-world practice assessment This invention verifies its effectiveness in a real-world environment through a series of actual kernel memory vulnerabilities. To ensure that this invention can accurately diagnose the causes of kernel memory vulnerabilities in the real world, the testing process selected 65 kernel memory vulnerabilities reported by the Syzbot vulnerability discovery platform. The kernel versions where the vulnerabilities exist cover 5.0 to 5.14. The vulnerability types are diverse, including general protection errors, kernel page faults, null pointer dereferences, use after free, and slab out-of-bounds errors. The complexity of the vulnerabilities varies, with their proof-of-concept programs ranging from 29 to 7176 lines of C code, and their patches ranging from 1 to 150 lines of C code. The testing includes kernel memory vulnerabilities of multiple versions, types, and varying degrees of complexity, which can fully evaluate the effectiveness of this invention.

[0053] This invention was applied to the causal diagnosis of these collected kernel memory vulnerabilities, and the accuracy of the causal diagnosis results was evaluated by two experienced security experts. Of the 65 kernel memory vulnerabilities identified, this invention successfully diagnosed the causes of 54, achieving an accuracy rate of 83.1%. In contrast, the widely used vulnerability introduction submission locator tool SyzbotCauseBisection only successfully diagnosed 19 vulnerabilities, achieving an accuracy rate of 29.2%. These test results demonstrate that the causal chain analysis-based kernel memory vulnerability causal diagnosis method proposed in this invention significantly outperforms existing tools in terms of accuracy in causal diagnosis.

[0054] To evaluate the effectiveness of the vulnerability cause diagnosis results provided by this invention in enhancing analysts' understanding of vulnerabilities, we designed a questionnaire. The questionnaire consisted of three parts. The first part collected participants' identity characteristics, including their years of experience in kernel vulnerability analysis and their specific areas of expertise. The second part included vulnerability cases from a test set. These cases provided both the original vulnerability crash report and the vulnerability cause diagnosis report from this invention. Participants first reviewed the original vulnerability crash report and rated their subjective understanding of the vulnerability on a scale of 1-5. Then, participants reviewed the vulnerability cause diagnosis report provided by this invention and again rated their subjective understanding of the vulnerability on a scale of 1-5. The difference in vulnerability understanding scores indicates whether this invention enhances analysts' understanding of vulnerabilities. The survey invited 19 professionals working in kernel vulnerability analysis. The results showed that after reviewing only the original vulnerability crash report, the average vulnerability understanding score was only 2.28. However, after reviewing the vulnerability cause diagnosis report provided by this invention, the average vulnerability understanding score rose to 3.70. This survey result demonstrates that this invention has a positive effect on vulnerability analysts' understanding of vulnerabilities.

[0055] This invention proposes a method for diagnosing the causes of kernel memory vulnerabilities based on causal chain analysis. First, an execution state and semantic reconstruction module reconstructs the data dependency graph and function call tree from instruction-level trace data during the vulnerability triggering process. Combined with function modeling, this reconstructs the kernel execution state and kernel behavioral semantics. Next, an abnormal behavior identification module analyzes the kernel execution state and, combined with an anomaly model of kernel memory vulnerabilities, identifies abnormal execution behaviors. Finally, a causal chain analysis module employs dynamic programming-based causal chain analysis to analyze the causes of vulnerabilities from a series of abnormal kernel execution behaviors. Test results show that this invention can effectively diagnose the causes of kernel memory vulnerabilities, providing assistance to vulnerability analysts and facilitating subsequent vulnerability remediation work.

Claims

1. A method for diagnosing the causes of kernel memory vulnerabilities based on causal chain analysis, characterized in that, The specific steps are as follows: (1) Execution state and semantic reconstruction: The data dependency graph and call tree in the vulnerability triggering process are reconstructed from the original instruction-level trace data in the vulnerability triggering process. Combined with function modeling, the kernel execution state and kernel behavior semantics are reconstructed in a structured way. Among them, the call tree is the tree formed by the function call process in the vulnerability triggering process, and the data dependency graph is the graph formed by the data dependency relationship generated by the kernel execution in the vulnerability triggering process. (2) Abnormal behavior identification: Based on the restored kernel execution state and behavioral semantics, combined with the kernel memory vulnerability anomaly model, the abnormal behaviors generated during the kernel vulnerability triggering process are identified, and a set of abnormal behaviors is obtained. Each abnormal behavior contains the corresponding behavior type and related data nodes in the data dependency graph. Abnormal behaviors include memory access space anomalies, memory access time anomalies and memory access semantic anomalies. (3) Causal chain analysis: Based on the identified abnormal behaviors, and according to the relationship between these abnormal behaviors and vulnerability triggering, a dynamic programming method is used to construct the causal chain of abnormal behaviors, thereby locating the true cause of the vulnerability.

2. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 1, characterized in that, In step (1), the call tree is a tree-shaped data structure. The nodes in the call tree represent the stack frame of a function call, the edges between the nodes represent the function call relationship, the parent node on the edge is the caller, the child node is the callee, and the root node of the tree is a virtual node, representing the user-mode main function of the vulnerability proof-of-concept program. Based on the call tree, the complete call stack at any time when the kernel is executing can be restored by traversing the parent node of any node.

3. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 1, characterized in that, In step (1), the data dependency graph is a directed acyclic graph. The nodes in the data dependency graph are possible operands of the instruction. They also record the specific value, data size, data generation timestamp, and semantic label information of the operand of the node. Each node in the data dependency graph uniquely corresponds to a node in the call tree, representing the stack frame where the kernel execution is when the data node is generated. The edges in the graph represent the input-output dependencies between these operands.

4. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 3, characterized in that, Semantic tags are derived from how operands are generated, and the types include temporary values, constants, memory addresses, memory allocation addresses, memory release addresses, memory reads, memory writes, register reads, register writes, and unknowns.

5. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 1, characterized in that, In step (1), the semantics of memory management behavior are restored by using the method of memory management function identification: when the call instruction of memory management function is identified in the original trace data, the data node involved in the actual execution instruction of the corresponding memory management function is deleted in the data dependency graph and replaced with a unified function call entry. The operands of the function call entry include function parameters and function return values. The data dependency relationship involved is obtained according to the data dependency relationship of the original instruction. The corresponding call tree node is set as the call tree node corresponding to the function call instruction. At the same time, the semantic label of the corresponding operand node is modified according to the specific function function.

6. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 1, characterized in that, In step (2), the fine-grained classification of access space anomalies in the kernel memory vulnerability anomaly model includes accessing invalid base addresses, buffer out-of-bounds access, accessing invalid code addresses, misusing error codes as addresses, and misusing integer overflows as addresses. The fine-grained classification of access timing anomalies mainly includes two categories: use before initialization and use after release. Access semantic anomalies include type confusion. Type confusion refers to the fact that a value in memory is incorrectly used as another type different from its original type, and the original type cannot be converted to the used type.

7. The kernel memory vulnerability cause diagnosis method based on causal chain analysis according to claim 6, characterized in that, When accessing semantic anomaly identification, a type grid is constructed. The kernel implements data structure inheritance through nested structures. If the first member of a structure is also a structure, then the structure can be converted to the type of its first member. The partial order relationship between the structure type and the first member type is added to the type grid. If two types have a partial order relationship in the type grid, they can be converted to each other.

8. The kernel memory vulnerability cause analysis method based on causal chain analysis according to claim 1, characterized in that, In step (3), the causal chain analysis specifically includes: The causal analysis problem is modeled as a path search problem: finding the path from any anomalous behavior trigger in the data dependency graph that leads to the vulnerability trigger point and contains the maximum number of anomalous behaviors; all instructions involved in this path and the anomalous behaviors they trigger are called a causal chain, with the first anomalous behavior being the cause and the subsequent anomalous behavior being the effect; the instructions on the causal chain represent an anomalous behavior or an intermediate step in the causal relationship of anomalous behavior, and the source anomalous behavior of the causal chain is the analyzed cause of the vulnerability.

9. The kernel memory vulnerability cause analysis method based on causal chain analysis according to claim 8, characterized in that, The causal chain is solved using a dynamic programming algorithm, as follows: The state count(u) of the dynamic programming algorithm is defined as the number of anomalous behaviors among all paths ending at node u in the data dependency graph. Since the data dependency graph is directed acyclic, this dynamic programming state is iteratively updated using the following equation: , Where v represents the direct predecessor node of node u in the data dependency graph, count(v) is the final number of abnormal behaviors in all paths with node v as the endpoint, and UB(v) represents the number of abnormal behaviors represented by node v itself. By repeatedly traversing the nodes and edges in the data dependency graph and updating the count value of each node until the maximum value of count(crash) is found, the path where the causal chain is located is found, where crash represents the data node that directly causes the vulnerability to be triggered. By traversing backwards from the crash node along the update path of count, we can find all the nodes in the path containing the most abnormal behavior, as well as the instructions and abnormal behaviors corresponding to these nodes, and construct the final causal chain.

Images