A cross-control flow kernel vulnerability mining method for operating systems

Abstract

This invention proposes a cross-control flow kernel vulnerability mining method for operating systems, belonging to the field of vulnerability detection technology. The method comprises: S1, compiling Linux kernel code and generating LLVM IR, calling the LLVM API to read and parse the contents of the LLVM IR bytecode file, and obtaining the LLVM IR in the form of a memory object; S2, constructing a control flow graph for each function and identifying error codes; S3, identifying functions that return error codes, target functions, and code error variables; S4, traversing the control flow graphs of each function and identifying memory pointers; S5, constructing a control flow graph for key variables; S6, identifying security checks and memory releases; and S7, generating a vulnerability report. This method addresses the problems of being difficult to apply to the entire operating system kernel, not considering cross-control flow data propagation, and being unable to identify vulnerabilities with complex characteristics.

Description

Technical Field

[0001] The present invention relates to a cross-control flow kernel vulnerability mining method for an operating system, belonging to the technical field of vulnerability detection. Background Art

[0002] Vulnerability testing is an integral part of cybersecurity. It can quickly identify security risks within systems, applications, or networks, helping to assess and mitigate risks that could lead to data breaches or service disruptions. Regular vulnerability testing can prevent hackers from exploiting unpatched security flaws.

[0003] Operating system kernel vulnerability mining can play an important role in many fields, including network security, enterprise management, government supervision and many other aspects.

[0004] The limitations of existing technologies include difficulty in applying to the entire operating system kernel, failure to consider cross-control flow data propagation, and inability to identify vulnerabilities with complex characteristics. Specifically, they are:

[0005] Static methods typically require complex calculations. While these methods can complete calculations within a reasonable timeframe when analyzing relatively simple open source projects, they can be prohibitively time-consuming for projects with large code volumes, such as operating system kernels. Software fault injection methods struggle to trigger complex kernel code execution paths, making it difficult to discover vulnerabilities within these codebases.

[0006] Existing static and taint analysis methods fail to consider the case where data propagates across control flows when analyzing code for issues. These methods typically interrupt the analysis process when encountering such a situation, resulting in missed or false positives and significantly reduced accuracy.

[0007] Existing static methods and taint analysis methods usually only focus on the characteristics of specific types of vulnerabilities, so they have considerable limitations when analyzing problems, resulting in them only being able to discover specific types of vulnerabilities. Summary of the Invention

[0008] A brief overview of the present invention is provided below to provide a basic understanding of certain aspects of the present invention. It should be understood that this overview is not an exhaustive overview of the present invention. It is not intended to identify key or important aspects of the present invention, nor is it intended to limit the scope of the present invention. Its purpose is simply to present certain concepts in a simplified form as a prelude to the more detailed description discussed later.

[0009] In view of this, in order to solve the technical problems existing in the prior art, the present invention provides a cross-control flow kernel vulnerability mining method for operating systems.

[0010] Solution 1: A cross-control flow kernel vulnerability mining method for operating systems, including:

[0011] S1. Compile the Linux kernel code and generate LLVM IR. Call the LLVM API to read and parse the LLVM IR bytecode file to obtain the LLVM IR in the form of a memory object.

[0012] S2. Build the control flow graph of each function and identify error codes;

[0013] S3, identifying the return error code function, target function and code error variable;

[0014] S4, traverse the control flow graph of each function and identify memory pointers;

[0015] S5. Construct key variable control flow graph;

[0016] S6, identify security checks and memory release;

[0017] S7. Make a vulnerability report.

[0018] Preferably, the steps of constructing a control flow graph of each function and identifying error codes include:

[0019] S21. Based on the LLVM IR in the form of memory objects, construct the control flow graph of each function in the Linux kernel code. Describe the control flow graph as G(f) = (V, E), f∈F, where F is the set of functions in the kernel, f is a function in the set, G is the control flow graph corresponding to the function, V is the set of nodes, a node is a basic block in the function, and E is the set of directed edges, which are the control flow transfer relationships between basic blocks.

[0020] S22. Collect functions that may be used for indirect calls based on the LLVM IR in the form of memory objects and save them to set I.

[0021] S23, traverse the control flow graph of each function, check the function call instructions in the basic block, collect all indirect call points, search for matching functions in set I according to the number and type of parameters used in the function call, as potential indirect call objects, build a mapping Ind, and the key of the mapping Ind is the indirect call point;

[0022] S24. Collect error codes defined in the Linux source code and save them to the set Err.

[0023] The steps to identify the function that returns the error code, the target function, and the code error variable include:

[0024] S31. Traverse each node in the control flow graph and check the operands used by each instruction in the basic block. If the operand is equal to the negative of an error code, mark it as an error code and save the operand marked as the error code to the set ErrSrc. If the operand is a null pointer, save the null pointer operand to the set NullSrc.

[0025] S32. Start the trace propagation process with one of the operands ErrSrc and NullSrc as the starting point; if an instruction uses the traced operand, the value generated by the instruction is marked; if the operand of an instruction is a marked value, the value generated by the instruction is also marked; if the operand of a return instruction is a marked value, the function where the instruction is located is saved to the set ErrRetFunc; if a store instruction saves the marked value to the memory area pointed to by a parameter pointer of a function, the function where the instruction is located is also saved to the set ErrRetFunc;

[0026] S33. Traverse the control flow graph of each function and check the function call instructions therein. If the called object exists in the set ErrRetFunc, add the function to the set TargetFunc; add the variable that stores the error code to the set ErrRetVar.

[0027] Preferably, the step of traversing the control flow graph of each function and identifying the memory pointer includes:

[0028] S41. Traverse the control flow graph of each function and check whether there is a call instruction for calling a Linux memory allocation-related function in the function call instruction. If not, skip it; if so, track the propagation process of the memory pointer returned by the function; if there is a return instruction that uses the memory pointer, add the current function to the set MemAllocFunc; if there is a store instruction that saves the memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc;

[0029] S42. Traverse the control flow graph of each function. If the function is in the set MemAllocFunc, skip it. If not, check whether there is a call to a function in MemAllocFunc in the function call instruction. According to the memory pointer returned by the callee, track how the corresponding variable that stores the memory pointer is propagated. If there is a return instruction that uses the stored memory pointer, add the current function to the set MemAllocFunc. If there is a store instruction that saves the stored memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc.

[0030] S43. Repeat S42 until there are no new functions in the set MemAllocFunc;

[0031] S44. Traverse the control flow graph of each function and check whether there is a call to the function in MemAllocFunc in the function call instruction; if the called object exists in the set MemAllocFunc, add the current function to the set TargetFunc; save the variable that stores the memory pointer to the set MemRetVar.

[0032] Preferably, the steps of constructing a key variable control flow graph include:

[0033] Merge the sets ErrRetVar and MemRetVar into KeyVar, where the variables are key variables; for each function, construct the key variable control flow graph KG(f) = (Var, Acc), f∈F according to the control flow graph, where F is the set of functions in the kernel, f is the function in the set, Var is the set of key variables, and Acc is the set of access relations between key variables;

[0034] In a control flow graph G of function f, a variable is in KeyVar, add the variable to the set Var;

[0035] Add the parameter variables of function f to the set Var;

[0036] If a function instruction uses variable A in the set Var, add the function instruction to the set Var; if the function instruction saves the return value to another variable B, or saves A to another variable C, add B or C to the set Var, and add a directed edge in Acc from A to B or C; repeat this process until KG(f) no longer changes.

[0037] Preferably, the steps of identifying security checks and memory release include:

[0038] For each key variable in KeyVar, start from the variable control flow graph KG(f) of the function f where the key variable is located and track its propagation process;

[0039] If there is a point in Var that accesses a key variable, it will be marked; if other points in Var access the marked point, they will also be marked; if the marked point is a function call instruction, enter the key variable control flow graph corresponding to the called function, mark the corresponding parameters, and continue to track the propagation of the parameters;

[0040] For the function call instructions in Ind, enter the key variable control flow graph corresponding to each potential call object and continue tracking; if the marked point is a return instruction, and it is entered from the previous function to the current function, return to the previous function and mark its return value variable; if it is found that the storage instruction saves the marked value to the function parameter, and it is entered from the previous function to the current function, return to the previous function and mark its corresponding parameter variable; if it is found that the storage instruction saves the marked value to a field of the global variable, mark the global variable and field, and find all places where the global variable and field are used, and continue to track its propagation; during the tracking process, if it is found that the marked point is a comparison instruction, and the comparison object is the negative of the integer value in Err, stop tracking and record the tracking path as successful; if the comparison object is a null pointer, add one Verified pointer mark and continue tracing; if the marked point is found to be a function call instruction, and the callee name contains "release", "free", "put" and "destroy", or the function name is kfree(), kmem_cache_free(), kvfree() and vfree(), then stop tracing and record the tracing path as success; if a storage instruction is found to save an unmarked value to a marked variable, then stop tracing and record the path as failure; if it is found that it is not accessed by other points during the tracing process, then stop tracing and record the path as failure; for key variables of memory pointer type, if it is found during the tracing process that they are used to calculate related instructions or load instructions, but the tracing path does not have a verified pointer mark, then stop tracing and record the path as failure.

[0041] Preferably, the steps of reporting a vulnerability include:

[0042] For trace paths recorded as failed, the report may contain loopholes;

[0043] For the case where the key variable is an error code, if it fails because it is not accessed by other points, an error code unhandled vulnerability is reported;

[0044] If it fails due to being overwritten during propagation, an error code propagation failure vulnerability is reported;

[0045] For cases where the critical variable is a memory pointer, if it fails because it is not accessed by other points, a resource leak vulnerability is reported;

[0046] If it fails because a pointer is used without validation, a NULL pointer dereference vulnerability is reported;

[0047] For reported unhandled error code vulnerabilities, check how the return values ​​of error return functions corresponding to key variables are handled in the code;

[0048] For reported unhandled error code vulnerabilities, check how the return value of the error return function corresponding to the key variable is handled in the code; if for an error code return function, after analyzing all the calling instructions that call it, it is found that the return value is checked after more than 70% of the calling points, while the return value is not checked after the remaining calling points, then the unhandled error code vulnerability related to the error code return function will be reported as a severe unhandled error code vulnerability.

[0049] Solution 2: An electronic device includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the cross-control flow kernel vulnerability mining method for an operating system described in Solution 1.

[0050] Solution 3: A computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the cross-control flow kernel vulnerability mining method for operating systems described in Solution 1.

[0051] The beneficial effects of the present invention are as follows:

[0052] 1. This method detects the entire Linux kernel based on the common characteristics of error handling vulnerabilities, and customizes analysis rules specifically for Linux. These rules cover various common error handling patterns, enabling the system to systematically identify and report vulnerabilities in error handling code. By capturing the common characteristics of error handling code, it can effectively detect vulnerabilities caused by improper error handling, providing more comprehensive coverage than traditional methods.

[0053] 2. The present invention can associate the control flows analyzed in the Linux kernel for joint analysis. This method can associate the separated control flows in the Linux kernel for joint analysis, so that the taint propagation between different control flows can be accurately tracked, thereby significantly improving the accuracy and coverage of vulnerability detection.

[0054] 3. The present invention can identify serious error handling vulnerabilities from ordinary vulnerability reports. By analyzing the processing of error codes in different callers, the system can identify those vulnerabilities that may cause major security risks. Through this in-depth analysis method, it can effectively distinguish between ordinary vulnerabilities and critical vulnerabilities that may cause serious consequences, thereby improving the practicality and credibility of the detection results. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0056] Figure 1 This is a flow chart of a cross-control flow kernel vulnerability mining method for operating systems. DETAILED DESCRIPTION

[0057] To make the technical solutions and advantages of the embodiments of the present invention more clearly understood, exemplary embodiments of the present invention are further described in detail below with reference to the accompanying drawings. It should be noted that the embodiments described are only a portion of the embodiments of the present invention, and are not an exhaustive list of all embodiments. It should be noted that the embodiments of the present invention and the features thereof may be combined with each other unless they conflict.

[0058] Example 1: Reference Figure 1 This embodiment describes a method for cross-control flow kernel vulnerability mining for an operating system, including:

[0059] S1. Compile the Linux kernel code and generate LLVM IR. Call the LLVM API to read and parse the LLVM IR bytecode file to obtain the LLVM IR in the form of a memory object.

[0060] S2. Build the control flow graph of each function and identify error codes;

[0061] S21. Based on the LLVM IR in the form of memory objects, construct the control flow graph of each function in the Linux kernel code. Describe the control flow graph as G(f) = (V, E), f∈F, where F is a set of functions, f is a function in the kernel, G is the control flow graph corresponding to the function, V is a set of nodes, a node is a basic block in the function, and E is a set of directed edges, which are the control flow transfer relationships between basic blocks.

[0062] S22. Collect functions that may be used for indirect calls based on the LLVM IR in the form of memory objects and save them into set I; function pointers of the functions in the set are either saved into global variables or local variables, or used as parameters of function call instructions.

[0063] S23, traverse the control flow graph of each function, check the function call instructions in the basic block, collect all indirect call points, search for matching functions in set I according to the number and type of parameters used in the function call, as potential indirect call objects, build a mapping Ind, and the key of the mapping Ind is the indirect call point;

[0064] An indirect call site is a function call instruction, but this type of function call instruction uses the value of a variable to make a function call;

[0065] If the number and type of parameters of the function call instruction match the number and type of parameters of a function in set I, it is considered a match;

[0066] The key of the mapping Ind is the indirect call point, and the value is a set containing all the functions that successfully match the indirect call point in the set I.

[0067] S24. Collect error codes defined in the Linux source code and save them to the Err set;

[0068] S3, identifying the return error code function, target function and code error variable;

[0069] S31. Traverse each node in the control flow graph and check the operands used by each instruction in the basic block. If the operand is equal to the negative of an error code, mark it as an error code and save the operand marked as the error code to the set ErrSrc. If the operand is a null pointer, save the null pointer operand to the set NullSrc.

[0070] S32. Start the trace propagation process with one of the operands ErrSrc and NullSrc as the starting point; if an instruction uses the traced operand, the value generated by the instruction is marked; if the operand of an instruction is a marked value, the value generated by the instruction is also marked; if the operand of a return instruction is a marked value, the function where the instruction is located is saved to the set ErrRetFunc; if a store instruction saves the marked value to the memory area pointed to by a parameter pointer of a function, the function where the instruction is located is also saved to the set ErrRetFunc;

[0071] S33. Traverse the control flow graph of each function and check the function call instructions therein. If there is a called object in the set ErrRetFunc, add the function to the set TargetFunc; add the variable that stores the error code to the set ErrRetVar;

[0072] Among them, the error code function is, the error code is a series of positive integers, representing different error information, the positive integer is negated and then used as the return value of the error code function;

[0073] The objective function is a function that further determines whether there is a vulnerability;

[0074] The variable for the error code is the variable storing the return value or the pointer parameter variable.

[0075] S4, traverse the control flow graph of each function and identify memory pointers;

[0076] S41. Traverse the control flow graph of each function and check whether there is a call instruction for calling a Linux memory allocation-related function in the function call instruction. If not, skip it; if so, track the propagation process of the memory pointer returned by the function; if there is a return instruction that uses the memory pointer, add the current function to the set MemAllocFunc; if there is a store instruction that saves the memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc;

[0077] S42. Traverse the control flow graph of each function. If the function is in the set MemAllocFunc, skip it. If not, check whether there is a call to a function in MemAllocFunc in the function call instruction. According to the memory pointer returned by the callee, track how the corresponding variable that stores the memory pointer is propagated. If there is a return instruction that uses the stored memory pointer, add the current function to the set MemAllocFunc. If there is a store instruction that saves the stored memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc.

[0078] The variable storing the memory pointer may be a variable storing the return value of a function call instruction, or may be a pointer parameter of a function call instruction.

[0079] S43. Repeat S42 until there are no new functions in the set MemAllocFunc;

[0080] S44. Traverse the control flow graph of each function and check whether there is a call to a function in MemAllocFunc in the function call instruction; if the called object exists in the set MemAllocFunc, add the current function to the set TargetFunc; save the variable that stores the memory pointer to the set MemRetVar;

[0081] The variable of the memory pointer is a variable of a return value of a call instruction or a pointer parameter variable.

[0082] S5. Construct key variable control flow graph;

[0083] Merge the sets ErrRetVar and MemRetVar into KeyVar, where the variables are key variables; for each function, construct the key variable control flow graph KG(f) = (Var, Acc), f∈F according to the control flow graph, where F is the set of functions in the kernel, f is the function in the set, Var is the set of key variables, and Acc is the set of access relations between key variables;

[0084] In a control flow graph G of function f, a variable is in KeyVar, add the variable to the set Var;

[0085] Add the parameter variables of function f to the set Var;

[0086] If a function instruction uses variable A in the set Var, add the function instruction to the set Var; if the function instruction saves the return value to another variable B, or saves A to another variable C, add B or C to the set Var and add a directed edge from A to B or C in Acc; repeat this process until KG(f) no longer changes;

[0087] S6, identify security checks and memory release;

[0088] For each key variable in KeyVar, start from the variable control flow graph KG(f) of the function f where the key variable is located and track its propagation process;

[0089] If there is a point in Var that accesses a key variable, it will be marked; if other points in Var access the marked point, they will also be marked; if the marked point is a function call instruction, enter the key variable control flow graph corresponding to the called function, mark the corresponding parameters, and continue to track the propagation of the parameters;

[0090] For the function call instructions in Ind, enter the key variable control flow graph corresponding to each potential call object and continue tracking; if the marked point is a return instruction, and it is entered from the previous function to the current function, return to the previous function and mark its return value variable; if it is found that the storage instruction saves the marked value to the function parameter, and it is entered from the previous function to the current function, return to the previous function and mark its corresponding parameter variable; if it is found that the storage instruction saves the marked value to a field of the global variable, mark the global variable and field, and find all places where the global variable and field are used, and continue to track its propagation; during the tracking process, if it is found that the marked point is a comparison instruction, and the comparison object is the negative of the integer value in Err, stop tracking and record the tracking path as successful; if the comparison object is a null pointer, add one Verified pointer mark and continue tracing; if the marked point is found to be a function call instruction, and the callee name contains "release", "free", "put" and "destroy", or the function name is kfree(), kmem_cache_free(), kvfree() and vfree(), then stop tracing and record the tracing path as successful; if a storage instruction is found to save an unmarked value to a marked variable, then stop tracing and record the path as failed; if it is found that it is not accessed by other points during the tracing process, then stop tracing and record the path as failed; for key variables of memory pointer type, if it is found to be used to calculate related instructions or load instructions during the tracing process, but the tracing path does not have a verified pointer mark, then stop tracing and record the path as failed;

[0091] S7. Make a vulnerability report.

[0092] For trace paths recorded as failed, the report may contain loopholes;

[0093] For the case where the key variable is an error code, if it fails because it is not accessed by other points, an error code unhandled vulnerability is reported;

[0094] If it fails due to being overwritten during propagation, an error code propagation failure vulnerability is reported;

[0095] For cases where the critical variable is a memory pointer, if it fails because it is not accessed by other points, a resource leak vulnerability is reported;

[0096] If it fails because a pointer is used without validation, a NULL pointer dereference vulnerability is reported;

[0097] For reported unhandled error code vulnerabilities, check how the return values ​​of error return functions corresponding to key variables are handled in the code;

[0098] For reported unhandled error code vulnerabilities, check how the return value of the error return function corresponding to the key variable is handled in the code; if for an error code return function, after analyzing all the calling instructions that call it, it is found that the return value is checked after more than 70% of the calling points, while the return value is not checked after the remaining calling points, then the unhandled error code vulnerability related to the error code return function will be reported as a severe unhandled error code vulnerability.

[0099] During the analysis of multiple versions of the Linux kernel, this embodiment identified 34 error handling vulnerabilities, 25 of which were already in the CVE list. After reporting the new vulnerabilities to the Linux kernel maintainers, at least 4 were confirmed.

[0100] Example 2: The computer device of the present invention may include a processor and memory, such as a single-chip microcomputer including a central processing unit. Furthermore, the processor is configured to execute a computer program stored in the memory to implement the steps of the aforementioned method for cross-control flow kernel vulnerability discovery for an operating system.

[0101] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0102] The memory may primarily include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function (such as a sound playback function or an image playback function); and the data storage area may store data generated based on the use of the mobile phone (such as audio data, a phone book, etc.). Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0103] Embodiment 3: Computer readable storage medium embodiment.

[0104] The computer-readable storage medium of the present invention can be any form of storage medium that can be read by the processor of a computer device, including but not limited to non-volatile memory, volatile memory, ferroelectric memory, etc. The computer-readable storage medium stores a computer program. When the processor of the computer device reads and executes the computer program stored in the memory, the steps of the above-mentioned cross-control flow kernel vulnerability mining method for an operating system can be implemented.

[0105] The computer program includes computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0106] Although the present invention has been described with respect to a limited number of embodiments, it will be apparent to those skilled in the art, having benefit of the foregoing description, that other embodiments are contemplated within the scope of the invention thus described. Furthermore, it should be noted that the language used in this specification has been selected primarily for readability and didactic purposes, rather than for the purpose of explaining or limiting the subject matter of the present invention. Consequently, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the present invention is intended to be illustrative rather than restrictive of the scope of the invention, which is defined by the appended claims.

Claims

1. A cross-control flow kernel vulnerability mining method for operating systems, characterized by: include: S1. Compile the Linux kernel code and generate LLVM IR. Call the LLVM API to read and parse the contents of the LLVM IR bytecode file to obtain the LLVM IR in the form of a memory object. S2. Build the control flow graph of each function and identify error codes; S3, identifying the return error code function, target function and code error variable; S4, traverse the control flow graph of each function and identify memory pointers; S5. Construct a control flow graph of key variables; S6, identify security checks and memory release; S7. Report a vulnerability. The steps to identify safety checks and memory releases include: For each key variable in KeyVar, start from the variable control flow graph KG(f) of the function f where the key variable is located and track its propagation process; If there is a point in Var that accesses a key variable, it will be marked; if other points in Var access the marked point, they will also be marked; if the marked point is a function call instruction, enter the key variable control flow graph corresponding to the called function, mark the corresponding parameters, and continue to track the propagation of the parameters; For the function call instructions in Ind, enter the key variable control flow graph corresponding to each potential call object and continue tracing; if the marked point is a return instruction, and it is entered from the previous function to the current function, return to the previous function and mark its return value variable; if it is found that the storage instruction saves the marked value to the function parameter, and it is entered from the previous function to the current function, return to the previous function and mark its corresponding parameter variable; if it is found that the storage instruction saves the marked value to a field of the global variable, mark the global variable and field, and find all places where the global variable and field are used, and continue to track its propagation; during the tracing process, if it is found that the marked point is a comparison instruction, and the comparison object is the negative of the integer value in Err, stop tracing and record the tracing path as successful; if the comparison object is a null pointer, add a The pointer mark has been verified and tracing continues; if the marked point is found to be a function call instruction, and the callee name contains "release", "free", "put" and "destroy", or the function name is kfree(), kmem_cache_free(), kvfree() and vfree(), then stop tracing and record the tracing path as success; if it is found that a storage instruction saves an unmarked value to a marked variable, then stop tracing and record the path as failure; if it is found that it is not accessed by other points during the tracing process, then stop tracing and record the path as failure; for key variables of memory pointer type, if it is found during the tracing process that they are used to calculate related instructions or load instructions, but the tracing path does not have a verified pointer mark, then stop tracing and record the path as failure.

2. The method for mining cross-control flow kernel vulnerabilities in an operating system according to claim 1, characterized in that: The steps to construct the control flow graph of each function and identify the error code include: S21. Based on the LLVM IR in the form of memory objects, construct the control flow graph of each function in the Linux kernel code. Describe the control flow graph as G(f) = (V, E), f∈F, where F is the set of functions in the kernel, f is a function in the set, G is the control flow graph corresponding to the function, V is the set of nodes, a node is a basic block in the function, and E is the set of directed edges, which are the control flow transfer relationships between basic blocks. S22. Collect functions that may be used for indirect calls based on the LLVM IR in the form of memory objects and save them to set I. S23, traverse the control flow graph of each function, check the function call instructions in the basic block, collect all indirect call points, search for matching functions in set I according to the number and type of parameters used in the function call, as potential indirect call objects, build a mapping Ind, and the key of the mapping Ind is the indirect call point; S24. Collect error codes defined in the Linux source code and save them to the set Err.

3. The method for mining cross-control flow kernel vulnerabilities for an operating system according to claim 1, characterized in that: The steps for identifying the function that returns the error code, the target function, and the code error variable include: S31. Traverse each node in the control flow graph and check the operands used by each instruction in the basic block. If the operand is equal to the negative of an error code, mark it as an error code and save the operand marked as the error code to the set ErrSrc. If the operand is a null pointer, save the null pointer operand to the set NullSrc. S32. Start the trace propagation process with one of the operands ErrSrc and NullSrc as the starting point; if an instruction uses the traced operand, the value generated by the instruction is marked; if the operand of an instruction is a marked value, the value generated by the instruction is also marked; if the operand of a return instruction is a marked value, the function where the instruction is located is saved to the set ErrRetFunc; if a store instruction saves the marked value to the memory area pointed to by a parameter pointer of a function, the function where the instruction is located is also saved to the set ErrRetFunc; S33. Traverse the control flow graph of each function and check the function call instructions therein. If the called object exists in the set ErrRetFunc, add the function to the set TargetFunc; add the variable that stores the error code to the set ErrRetVar.

4. The method for mining cross-control flow kernel vulnerabilities in an operating system according to claim 1, wherein: Traversing the control flow graph of each function, the steps to identify the memory pointer include: S41. Traverse the control flow graph of each function and check whether there is a call instruction for calling a Linux memory allocation-related function in the function call instruction. If not, skip it; if so, track the propagation process of the memory pointer returned by the function; if there is a return instruction that uses the memory pointer, add the current function to the set MemAllocFunc; if there is a store instruction that saves the memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc; S42. Traverse the control flow graph of each function. If the function is in the set MemAllocFunc, skip it. If not, check whether there is a call to a function in MemAllocFunc in the function call instruction. According to the memory pointer returned by the callee, track how the corresponding variable that stores the memory pointer is propagated. If there is a return instruction that uses the stored memory pointer, add the current function to the set MemAllocFunc. If there is a store instruction that saves the stored memory pointer to the memory pointed to by the function pointer parameter, also add the current function to the set MemAllocFunc. S43. Repeat S42 until there are no new functions in the set MemAllocFunc; S44. Traverse the control flow graph of each function and check whether there is a call to the function in MemAllocFunc in the function call instruction; if the called object exists in the set MemAllocFunc, add the current function to the set TargetFunc; save the variable that stores the memory pointer to the set MemRetVar.

5. The method for mining cross-control flow kernel vulnerabilities in an operating system according to claim 1, wherein: The steps to construct the control flow graph of key variables include: Merge the sets ErrRetVar and MemRetVar into KeyVar, where the variables are key variables; for each function, construct the key variable control flow graph KG(f) = (Var, Acc), f∈F according to the control flow graph, where F is the set of functions in the kernel, f is the function in the set, Var is the set of key variables, and Acc is the set of access relations between key variables; In a control flow graph G of function f, a variable is in KeyVar, add the variable to the set Var; Add the parameter variables of function f to the set Var; If a function instruction uses variable A in the set Var, add the function instruction to the set Var; if the function instruction saves the return value to another variable B, or saves A to another variable C, add B or C to the set Var, and add a directed edge in Acc from A to B or C; repeat this process until KG(f) no longer changes.

6. The method for mining cross-control flow kernel vulnerabilities in an operating system according to claim 1, characterized in that: The steps for reporting a vulnerability include: For trace paths recorded as failed, the report may contain loopholes; For the case where the key variable is an error code, if it fails because it is not accessed by other points, an error code unhandled vulnerability is reported; If the propagation fails due to being overwritten during the process, an error code propagation failure vulnerability is reported; For cases where the critical variable is a memory pointer, if it fails because it is not accessed by other points, a resource leak vulnerability is reported; If it fails because a pointer is used without validation, a NULL pointer dereference vulnerability is reported; For reported unhandled error code vulnerabilities, check how the return values ​​of error return functions corresponding to key variables are handled in the code; For reported unhandled error code vulnerabilities, check how the return value of the error return function corresponding to the key variable is handled in the code; if for an error code return function, after analyzing all the calling instructions that call it, it is found that the return value is checked after more than 70% of the calling points, while the return value is not checked after the remaining calling points, then the unhandled error code vulnerability related to the error code return function will be reported as a severe unhandled error code vulnerability.

7. An electronic device, characterized in that: The invention comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method for mining cross-control flow kernel vulnerabilities for an operating system according to any one of claims 1 to 6 is implemented.

8. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the method for mining cross-control flow kernel vulnerabilities for an operating system according to any one of claims 1 to 6 is implemented.

Images