Vulnerability detection method and computing device

Abstract

The embodiment of the application provides a vulnerability detection method and a computing device. Test cases are generated according to a target optimization PASS of a compiler, which can ensure that the test cases are highly related to the characteristics of the target optimization PASS. Basic blocks of vulnerabilities are determined based on intermediate representation data obtained after the test cases are compiled, so that the position of potential vulnerabilities is located more accurately. The test cases are sliced according to the control flow characteristics of the basic blocks of vulnerabilities, and initial seeds generated based on this can have more targeted execution paths to reach the basic blocks of vulnerabilities, thereby significantly improving the directionality and efficiency of fuzz testing, increasing the vulnerability triggering probability and detection accuracy. By fusing the target distance and the optimization path coverage, high-value seeds are selected for mutation, and efficient and accurate detection of the Rust compiler optimization vulnerabilities is realized.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a vulnerability detection method and computing device. Background Technology

[0002] Rust is a new, memory-safe, statically typed programming language. It introduces the concepts of lifetime and ownership, and compared to traditional C / C++ programming languages, it ensures memory safety while achieving similar performance, greatly mitigating problems such as memory leaks, dangling pointers, buffer overflows, and data races in concurrent programming. Existing C codebases are very large, and manual refactoring is labor-intensive and costly. The Rust compiler can automatically convert C code to Rust.

[0003] During the compilation process, the Rust compiler performs a series of optimization stages, known as optimization passes. These passes transform the intermediate representation (IR) generated by the compiler to improve program execution efficiency. However, during optimization operations, these passes may introduce logical errors or unexpected behavior, resulting in compiler optimization vulnerabilities. To ensure compiler security, it is necessary to test for these vulnerabilities.

[0004] Existing testing methods select representative legitimate programs as seeds, then perform local perturbations or other mutations on the seeds to generate numerous variants as new input programs. These variants are then fed into the compiler for fuzzing with optimization passes enabled, thereby triggering potential optimization vulnerabilities. However, seed selection has limitations; it is difficult to cover the complex optimization behavior of the compiler's optimization passes, and the vulnerabilities cannot be precisely triggered, resulting in poor accuracy in vulnerability testing. Summary of the Invention

[0005] This application provides a vulnerability detection method, apparatus, and computing device, which can solve the problem that the selected seed cannot accurately trigger the vulnerability, resulting in poor accuracy of vulnerability testing.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a vulnerability detection method, which includes: generating test cases based on a compiler's target optimization pass; determining a vulnerability basic block based on intermediate representation data corresponding to the test cases; the intermediate representation data is obtained by compiling the test cases using a compiler; the vulnerability basic block is the basic block in the test cases where potential vulnerabilities are located; slicing the test cases according to the control flow characteristics of the vulnerability basic block to obtain vulnerability code fragments; generating an initial seed based on the vulnerability code fragments; performing targeted fuzz testing on the target optimization pass based on the initial seed; calculating the target distance and optimization path coverage of the initial seed if the test results indicate that no vulnerability exists; filtering the initial seed based on the target distance and optimization path coverage, and updating the filtered initial seed by mutation; the target distance represents the distance from the initial seed to the vulnerability basic block, and the optimization path coverage represents the proportion of the optimization path in the target optimization pass's execution optimization process in the execution path from the initial seed to the vulnerability basic block; and determining the vulnerability triggered by the initial seed if the test results indicate that a vulnerability exists.

[0007] Based on this scheme, test cases are generated according to the compiler's target optimization pass, ensuring a high degree of correlation between the test cases and the characteristics of the target optimization pass. The intermediate representation data obtained after compiling the test cases is used to determine the vulnerability base block, making the location of potential vulnerabilities more precise. Test cases are sliced ​​according to the control flow characteristics of the vulnerability base block, and the initial seed generated based on this slice has an execution path that more specifically reaches the vulnerability base block, thus significantly improving the directionality and efficiency of fuzzing, increasing the probability of vulnerability triggering and detection accuracy. By fusing target distance and optimization path coverage, high-value seeds are selected for mutation, achieving efficient and accurate detection of Rust compiler optimization vulnerabilities.

[0008] In one possible implementation, test cases are generated based on the compiler's target optimization pass, including: obtaining the logical information of the target optimization pass and the syntactic constraint information of the RUST language based on the compiler's information storage file; constructing a prompt word template based on the logical information and syntactic constraint information; inputting the prompt word template into the large language model to generate multiple prompt words; and inputting the multiple prompt words into the large language model to generate multiple initial test cases.

[0009] Based on this solution, test cases are generated according to the logical information of the optimized PASS and the syntactic constraints of the RUST language to ensure that they meet the requirements of syntactic correctness and semantic triggerability, thereby increasing the probability of triggering vulnerabilities.

[0010] In one possible implementation, before determining the vulnerability basic block based on the intermediate representation data corresponding to the test cases, the following steps are also included: using a compiler to compile multiple initial test cases using a target optimization PASS; deleting the initial test cases if compilation fails; and detecting the optimization coverage of the target optimization PASS on the initial intermediate representation data of the initial test cases if compilation succeeds. The optimization coverage represents the proportion of the optimization path of the target optimization PASS in the initial intermediate representation data. If the optimization coverage is lower than a preset threshold, the initial test cases are deleted; if the optimization coverage is higher than or equal to the preset threshold, the initial test cases are retained.

[0011] Based on this solution, invalid or inefficient test cases are eliminated, significantly improving the accuracy and efficiency of subsequent intermediate representation analysis and vulnerability localization, thereby accurately identifying the basic block where potential vulnerabilities are located.

[0012] In one possible implementation, the intermediate representation data includes intermediate-level intermediate representation data and compiler framework intermediate representation data. Based on the intermediate representation data corresponding to the test cases, the vulnerability basic blocks are determined, including: when the test cases are secure code, detecting the basic block structure of the intermediate-level intermediate representation data before and after the target optimization PASS execution optimization process through the control flow graph; identifying the basic blocks whose basic block structure changes as vulnerability basic blocks; instrumenting the compiler framework intermediate representation data, and identifying the basic blocks optimized by the target optimization PASS as vulnerability basic blocks.

[0013] Based on this approach, for secure code, the vulnerability base block is located by comparing the changes in the control flow graph structure before and after optimization. At the same time, instrumentation marks are used to trace the intermediate representation data of the compiler framework, which can capture optimization behaviors at both the MIR and LLVM IR levels, effectively improving the accuracy of vulnerability base block location.

[0014] In one possible implementation, determining the vulnerability basic block based on the intermediate representation data corresponding to the test case further includes: detecting the vulnerability basic block based on preset rules when the test case is insecure code; the preset rules are used to characterize the conditions that trigger undefined behavior in the basic block corresponding to the insecure code; detecting the basic block structure of the intermediate representation data before and after the target optimization PASS execution optimization process through the control flow graph; identifying the basic block whose basic block structure has changed as the vulnerability basic block; instrumenting the intermediate representation data of the compiler framework, and identifying the basic block optimized by the target optimization PASS as the vulnerability basic block.

[0015] Based on this solution, for insecure code, a set of rules for triggering undefined behaviors is predefined. Combined with control flow graph structure analysis and instrumentation, a multi-dimensional and multi-level vulnerability basic block identification mechanism is realized, which can effectively detect vulnerability basic blocks and improve the probability of discovering vulnerabilities.

[0016] In one possible implementation, test cases are sliced ​​based on the control flow characteristics of the vulnerability basic blocks to obtain vulnerability code fragments, including: detecting the control flow boundaries of all vulnerability basic blocks; and performing context slicing on the vulnerability basic blocks based on the control flow boundaries to obtain vulnerability code fragments.

[0017] Based on this solution, by detecting the control flow boundary of the vulnerability's basic block, the scope of the vulnerability-related code context can be accurately determined. While retaining the necessary control flow context to reach the vulnerability's basic block, the vulnerability code fragment removes interference from irrelevant code, thus improving the efficiency of vulnerability detection.

[0018] In one possible implementation, targeted fuzz testing of the target optimization PASS is performed based on the initial seed, including: constructing a seed queue based on the initial seed; dividing the seed queue into high-priority seeds, medium-priority seeds, and low-priority seeds; wherein, the high-priority seed is the initial seed with the shortest target distance, the medium-priority seed is the initial seed with the highest optimization path coverage, and the low-priority seed is the initial seed other than the high-priority and medium-priority seeds; and selecting the initial seeds in sequence according to the priority order of the seed queue to perform targeted fuzz testing of the target optimization PASS.

[0019] Based on this scheme, by constructing a priority seed queue, the seeds that are closest to the vulnerability's basic block or have the highest coverage of the target's optimized path are selected first to participate in fuzzing, which effectively reduces invalid detections and improves the efficiency of targeted fuzzing.

[0020] In one possible implementation, initial seeds are selected based on the target distance and optimized path coverage, and the selected initial seeds are mutated and updated. This includes: calculating a weighted score for the target distance and optimized path coverage based on a preset weight coefficient to obtain a weighted score for the initial seeds; selecting target initial seeds based on the weighted score and mutating and updating the target initial seeds; the mutated and updated target initial seeds are used as new initial seeds, and the process returns to the step of performing a directional fuzzy test on the target optimization PASS based on the initial seeds.

[0021] Based on this solution, the performance of seeds in terms of path proximity and optimized coverage is comprehensively evaluated. High-quality seeds are selected for mutation and expansion, and the expanded seeds are fed back into the fuzzing process in a loop, forming a closed-loop iterative mechanism for continuous optimization, which effectively improves the vulnerability trigger rate and detection accuracy.

[0022] In one possible implementation, if the test results indicate that there are no vulnerabilities, the method further includes: detecting the duration of the timer; the timer starting to run after the initial seed is generated; stopping the directional fuzz test on the target optimization PASS if the duration reaches a duration threshold; and performing the steps of calculating the target distance and optimized path coverage of the initial seed if the duration does not reach the duration threshold.

[0023] Based on this solution, unlimited iterative testing is avoided when vulnerabilities are not triggered, ensuring that the testing process terminates within a controllable time frame and reducing the system's resource consumption rate.

[0024] Secondly, embodiments of this application also provide a vulnerability detection system, which includes: The test case generation module is used to generate test cases based on the compiler's target optimization PASS. The vulnerability base block determination module is used to determine the vulnerability base block based on the intermediate representation data corresponding to the test case; wherein, the intermediate representation data is obtained by compiling the test case by the compiler; the vulnerability base block is the base block in the test case where the potential vulnerability is located; The code slicing module is used to slice test cases based on the control flow characteristics of the vulnerability's basic block to obtain vulnerability code fragments; The seed generation module is used to generate an initial seed based on a vulnerable code snippet. The fuzz testing module is used to perform targeted fuzz testing on the target optimization PASS based on the initial seed; The seed update module is used to calculate the target distance and optimized path coverage of the initial seed when the test results indicate that there is no vulnerability; to filter the initial seed based on the target distance and optimized path coverage, and to perform mutation update on the filtered initial seed; where the target distance represents the distance from the initial seed to the vulnerability block, and the optimized path coverage represents the proportion of the optimized path in the target optimization PASS execution optimization process in the execution path from the initial seed to the vulnerability block. The vulnerability identification module is used to identify the vulnerability triggered by the initial seed when the test results indicate the presence of a vulnerability.

[0025] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0026] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0027] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0028] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0029] It is understood that the beneficial effects that the technical solutions provided in the second to sixth aspects above can achieve can be referred to the beneficial effects in the first aspect and any of its implementation methods, and will not be repeated here. Attached Figure Description

[0030] Figure 1 This is a flowchart of a vulnerability detection method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the test case generation method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the test case selection process provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the process of determining the basic block of a vulnerability, as provided in an embodiment of this application. Figure 5 This is a flowchart illustrating the vulnerability code fragment extraction method provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the targeted fuzz testing process provided in an embodiment of this application; Figure 7 This is a schematic diagram of the initial seed screening and mutation update process provided in the embodiments of this application; Figure 8 This is a schematic diagram of a vulnerability detection system provided in an embodiment of this application; Figure 9 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0032] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0033] Rust is a systems programming language designed with memory safety and high performance as its core design goals. It is widely used in operating system development, embedded systems, network services, and safety-critical software.

[0034] The Rust compiler is a tool that automatically translates C code into Rust code. The official Rust compiler is `rustc`, and its compilation process includes a complete series of stages: lexical analysis, syntax analysis, semantic analysis, High-level Intermediate Representation (HIR) generation, Mid-level Intermediate Representation (MIR) generation, borrow checking, MIR optimization, LLVM IR generation, LLVM optimization, and code generation. During the MIR and LLVM IR stages, the compiler performs multiple optimization passes to transform the intermediate representations (IRs) to improve program performance.

[0035] The Low Level Virtual Machine (LLVM) is an open-source project that provides efficient compilation, linking, and optimization capabilities for various programming languages. LLVM is a framework system for building compilers, written in C++, used to optimize the compile-time, link-time, run-time, and idle-time of programs written in any programming language. It remains open to developers and is compatible with existing scripts.

[0036] Intermediate representation (IR) is a representation of source code that is transformed during compilation into a form that lies between high-level language and target machine code, closer to the underlying level but independent of specific hardware.

[0037] The optimization process (PASS) refers to a series of techniques employed by the compiler to transform the intermediate representation (IR) or target code without altering the program's semantics (i.e., its external behavior). These transformations aim to improve program efficiency (e.g., execution speed), reduce resource consumption (e.g., memory and power consumption), or decrease code size. Examples include constant folding, dead code elimination, and inlining.

[0038] A basic block is the fundamental unit of a control flow graph. It consists of a set of sequentially executed instructions, has a unique entry and exit point, and does not contain branch or jump instructions. Basic blocks represent the fundamental granularity of compiler optimization and program analysis.

[0039] A control flow graph (CFG) is a directed graph that describes the execution flow of a program. Each node in the graph represents a basic block, and the edges represent the jump relationships between basic blocks.

[0040] Fuzz testing (or fuzzing) is an automated software testing technique that involves feeding a target program a large amount of random, abnormal, unexpected, or malformed data to observe whether the program crashes, leaks memory, fails assertions, exhibits undefined behavior, or has other security issues, thereby uncovering potential vulnerabilities.

[0041] Directed fuzzing is an advanced fuzzing technique that guides a fuzzing engine to prioritize exploring specific target locations in a program (such as high-risk functions, uncovered code paths, or known vulnerabilities), with a clear testing objective orientation.

[0042] A seed is the basic data used in fuzzing to generate test inputs. A seed can be a specific set of input files or data. New test inputs are generated by mutating the seed to detect vulnerabilities or anomalous behavior in the target program.

[0043] Large language model (LLM), also known as large model, is an artificial intelligence model that uses deep learning algorithms to learn language patterns and structures through training on large amounts of text data, thereby enabling it to understand and generate natural language text.

[0044] A prompt is input text used to guide or motivate a model to perform a specific task. Its purpose is to help the model understand the type of task the user wants to perform or the required output format. A prompt can be an instruction, a text description, or a parameter description in a certain format.

[0045] Slicing breaks down large-scale data or computational tasks into smaller sub-units.

[0046] The application scenarios of this application will be explained below.

[0047] Rust is a new statically typed programming language characterized by memory safety. It introduces the concepts of lifetime and ownership, and compared with traditional C / C++ programming languages, it can ensure memory safety while achieving similar performance.

[0048] The Rust compiler can automatically translate C code into Rust, improving translation efficiency. During compilation, the Rust compiler performs a series of optimization stages, known as optimization passes. These passes transform the intermediate representation (IR) generated by the compiler to improve program execution efficiency. However, optimization passes may introduce logical errors or unexpected behavior, resulting in compiler optimization vulnerabilities. To ensure compiler security, testing for these vulnerabilities is necessary.

[0049] When testing compiler optimization vulnerabilities, a representative legitimate program can be selected as a seed. This seed can then be mutated through local perturbations or other methods to generate numerous variants that serve as new input programs. These variants are then subjected to fuzzing by the compiler with optimization passes enabled, thereby triggering potential optimization vulnerabilities. However, seed selection has limitations; it is difficult to cover the complex optimization behavior of compiler optimization passes, and the vulnerabilities cannot be precisely triggered, resulting in poor accuracy in vulnerability testing.

[0050] Based on this, embodiments of this application provide a vulnerability detection method. The vulnerability detection method provided in this application can be applied to a computing device, which can be a server or a terminal device. Using the vulnerability detection method provided in this application, the basic block corresponding to a potential vulnerability can be identified, and a seed can be generated for that basic block. Fuzz testing using this seed can improve the seed's coverage and trigger accuracy for potential vulnerabilities, thereby significantly improving the detection accuracy of compiler optimization vulnerabilities. For seeds that do not trigger vulnerabilities, further filtering can be performed using target distance and optimized path coverage to determine a better mutation direction, improving mutation efficiency and vulnerability trigger probability.

[0051] The process of the vulnerability detection method is illustrated below with reference to the accompanying drawings.

[0052] Figure 1 This is a flowchart of a vulnerability detection method provided in an embodiment of this application. For example... Figure 1 As shown, the vulnerability detection method includes the following steps S100-S700: S100: Optimize PASS to generate test cases according to the compiler's goals.

[0053] In this embodiment, the target optimization PASS refers to the optimization PASS of the vulnerability to be detected. The compiler contains multiple optimization PASSes, each responsible for code transformations in different dimensions, such as loop unrolling, constant propagation, or dead code elimination. Testers can select a specific optimization PASS as the detection target to perform vulnerability detection.

[0054] Test cases can be test code input into the compiler to simulate vulnerability scenarios related to the target's optimized PASS. Therefore, corresponding test cases can be generated for the optimization logic of the target's optimized PASS to increase the probability of triggering the vulnerability.

[0055] In this embodiment, the computing device can construct prompt words based on the optimization logic features of the target optimized pass, and use a large language model to generate code snippets that conform to the optimization logic as test cases. The generated test cases are highly correlated with the path of the target optimized pass, thereby improving the coverage of the test cases for the target optimized pass.

[0056] S200: Determine the basic vulnerability block based on the intermediate representation data corresponding to the test case.

[0057] The computing device can use a compiler to compile test cases, perform optimization using the target optimization pass during compilation, and extract intermediate representation data from the compilation process. By analyzing the intermediate representation data, the vulnerability base block can be identified. In this embodiment, the vulnerability base block refers to the base block in the test case where the potential vulnerability is located, that is, the code unit that may produce erroneous behavior when the compiler executes the target optimization pass.

[0058] By accurately locating the code region affected by the optimization process, the vulnerability can be pinpointed to the basic block, providing a clear target location for subsequent targeted fuzzing.

[0059] S300: Based on the control flow characteristics of the vulnerability's basic block, the test case is sliced ​​to obtain the vulnerability code fragment.

[0060] Control flow characteristics reflect the branching, looping, and jumping relationships of the program execution path. By analyzing the control flow characteristics of the vulnerability's basic block, the necessary control flow context to reach the vulnerability's basic block can be determined. This allows for program slicing to extract code segments directly related to the vulnerability's basic block, i.e., the vulnerable code segments. For example, if the vulnerability's basic block is located in the `then` branch of an `if` statement, the slicing process will retain the conditional statements that determine that branch and the definitions of related variables, while removing irrelevant `else` branches or other independent code blocks.

[0061] Therefore, a vulnerable code snippet is a simplified program that is relatively complete in syntax and semantics, and whose execution path must pass through or affect the basic vulnerable block, which can provide a semantic basis for generating an accurate initial seed.

[0062] S400: Generates an initial seed based on a vulnerable code snippet.

[0063] In this embodiment of the application, the initial seed is a fuzz test input where the execution path can reach the vulnerability basic block.

[0064] A vulnerable code snippet is a program containing input points (such as function parameters, global variables, and file reads). An initial seed can generate specific values ​​for these input points, ensuring that the program's execution path traverses the vulnerable basic block, thereby triggering the corresponding potential vulnerability.

[0065] The computing device can generate initial seeds corresponding to vulnerable code fragments using a large model. There can be one or more initial seeds; this embodiment of the application does not limit the number.

[0066] S500: Performs directional fuzzy testing on the target PASS based on the initial seed.

[0067] During targeted fuzzing, the computing device can use test cases as test programs, starting with an initial seed. With target optimization PASS enabled, it controls the compiler to compile and run the test program. By monitoring for program crashes or undefined behavior, it determines whether the initial seed can trigger a vulnerability.

[0068] S600: Assuming no vulnerabilities are identified in the test results, calculate the target distance and optimized path coverage of the initial seed. Select the initial seed based on the target distance and optimized path coverage, and then update the selected initial seed through mutation.

[0069] If the initial seed does not trigger the vulnerability, the computing device can acquire more seeds to retest the target optimized pass. The effectiveness of the existing initial seed can be evaluated.

[0070] Here, target distance represents the distance from the initial seed to the vulnerable basic block, quantifying how close the program execution trajectory is to the vulnerable basic block given the current seed input. Optimized path coverage represents the proportion of optimized paths in the execution path from the initial seed to the vulnerable basic block where the target optimization pass is executed. This metric reflects the actual percentage of optimizations performed by the target optimization pass on the execution path of the initial seed. Seeds with smaller target distances (closer to triggering the vulnerability) and higher optimized path coverage can be prioritized, as they are more likely to trigger optimization behavior.

[0071] The computing device can perform mutation operations on the selected initial seeds to generate new test inputs. Mutation operations can generate a large number of new seeds, expanding and updating the seed pool, and then executing the next round of targeted fuzz testing.

[0072] S700: If the test results indicate the presence of a vulnerability, determine the vulnerability triggered by the initial seed.

[0073] If the compiler crashes or generates code incorrectly during testing, a vulnerability is identified. The computing device can determine the initial seed that triggers the vulnerability and identify the vulnerability information triggered by that initial seed, thus achieving vulnerability detection.

[0074] The vulnerability detection method provided in this application uses a large language model to perceive the logical characteristics of a target optimization pass, thereby generating test cases for the target optimization pass. By using the intermediate representation data corresponding to the test cases, the method locates the vulnerability base block where potential vulnerabilities reside and generates initial seeds that can reach the vulnerability base block. This allows for targeted fuzz testing of the target optimization pass, improving the accuracy of vulnerability detection. Filtering and mutating the initial seeds using target distance and optimization path coverage helps discover deep vulnerabilities in complex optimization scenarios, improving compiler reliability and the security of generated code.

[0075] The implementation of steps S100-S700 is illustrated below with reference to the accompanying drawings.

[0076] In step S100, test cases are generated by optimizing PASS according to the compiler's target.

[0077] Testers can choose target optimization passes for vulnerability detection. For example, a target optimization pass can be any optimization pass in the MIR optimization phase, such as Constant Propagation Pass, Dead Store Elimination Pass, Inliner Pass, Early Otherwise Branch Pass, Copy Propagation Pass, Simplify Control Flow Pass, etc.; or it can be any LLVM optimization pass in the LLVM IR optimization phase, such as Global Value Numbering (GVN), Memory to Register Promotion (mem2reg), Loop Simplify Pass, InstCombine Pass, Sparse Conditional Constant Propagation (SCCP), etc.

[0078] Different optimization passes correspond to different optimization logics, and their potential vulnerability triggering conditions also differ. Therefore, it is necessary to generate targeted test cases separately for each optimization pass. For example, if the optimization pass involves constant folding optimization, the test cases should include code structures that may trigger constant folding, such as assignment statements containing constant expressions, constant comparisons in conditional statements, etc. The generated test cases should cover as many typical scenarios and boundary conditions as possible that the optimization pass may encounter during actual compilation to ensure comprehensive testing. Test cases can be manually constructed program fragments with specific syntactic and semantic features, representative code examples obtained through analysis and screening of existing codebases, or test code generated using models.

[0079] Figure 2 This is a flowchart illustrating the test case generation method provided in an embodiment of this application. Figure 2 As shown, step S100 may include the following steps S110-S140: S110: A compiler-based information storage file that retrieves logical information about the target optimization pass and syntax constraint information for the Rust language.

[0080] The logical information of a target optimization pass can represent the core optimization objective of that pass, and may include specific behavioral characteristics such as loop unrolling, constant propagation, and dead code elimination. For example, the logical information may include the optimization purpose, such as eliminating redundant computations, improving data locality, simplifying the control flow structure, or reducing memory access overhead. The logical information may also include the specific algorithmic logic used to achieve the optimization objective, such as the loop condition judgment and iteration variable update rules in constant propagation, how the dead code elimination algorithm determines whether code is reachable and whether variables are used, or, in loop unrolling optimization, how to unroll the loop into several sequentially executed code blocks based on the loop count and loop body structure, or, in function inlining optimization, what conditions (such as function body size, call frequency, parameter passing method, etc.) determine whether to embed the code of the called function into the call point.

[0081] Rust possesses unique static guarantee mechanisms such as ownership, borrowing, and lifetime. The ownership mechanism stipulates that each value can only have one owner at any given time, and the value is automatically released when the owner variable goes out of scope. The borrowing mechanism allows code to access data through references without acquiring ownership, but stipulates that at any given time, either one mutable reference or multiple immutable references can exist simultaneously; neither can exist at the same time. The lifetime mechanism, marked with a lifetime parameter, ensures that the validity period of a reference strictly does not exceed the lifespan of the data it points to.

[0082] The syntax constraints information of the Rust language describes the syntax rules and type constraints that valid Rust code must satisfy, including all valid syntax rules of the Rust language (such as expression syntax, type system rules, feature constraints, etc.), type system rules, ownership semantics, lifecycle annotations, borrow checker requirements, and restrictions on unsafe blocks (such as the scope of unsafe blocks, safety invariants of raw pointer operations, etc.).

[0083] It should be noted that each optimization pass has a set of logical information, which is stored in a specific file of the compiler, referred to as the information storage file in this embodiment. In other words, the information storage file records the logical information corresponding to each optimization pass.

[0084] The information storage file may also record syntax constraints of the Rust language. In some embodiments, the information storage file may also record publicly available compiler optimization vulnerability data. This vulnerability data covers known optimization failure scenarios, undefined behaviors triggered by boundary conditions, etc., and computing devices can analyze detected vulnerabilities using the compiler optimization vulnerability data.

[0085] The logical information of the target optimization pass and the syntactic constraints of the Rust language can establish a standardized basis for the generation of test cases, clarify the optimization logic and language legality boundaries that the test cases must follow, and ensure that the generated test cases are test code that is strongly related to the target optimization pass, thereby increasing the accuracy of vulnerability detection.

[0086] S120: Construct prompt word templates based on logical information and grammatical constraint information.

[0087] The prompt word template can be structured, including logical information slots and grammatical constraint slots. Several logical information items can be selected based on the target PASS logic information and filled into the logical information slots, while several grammatical constraints can be selected based on the Rust language grammatical constraint information and filled into the grammatical constraint slots, forming a prompt word template with semantic integrity. For example, the computing device can randomly select a combination of logical information and grammatical constraints and fill it into the corresponding slots; alternatively, testers can actively select the logical information and grammatical constraints, which is not limited in this embodiment.

[0088] The prompt template can also include test case requirements. Test case requirements can be entered by the tester based on their needs, such as "generate a minimal test case that triggers a memory out-of-bounds access" or "cover all branches where lifecycle parameters conflict with borrow checks".

[0089] For example, the prompt template can be in the following form: [Optimized Pass logic information: loop unrolling threshold = 3 times, constant propagation trigger condition is "there is a reference to a runtime constant variable in the basic block, and the variable is assigned the same literal constant value in all predecessor paths of the control flow"] + [Rust syntax constraints: ownership is immutable and modification is prohibited during borrowing, unsafe blocks need to be manually released] + [Test case requirements: cover loop unrolling trigger and constant propagation failure scenarios].

[0090] The logical information includes two parts: "loop unrolling threshold = 3 times" and "constant propagation trigger condition is "there is a reference to a runtime constant variable in the basic block, and the variable is assigned the same literal constant value in all preceding paths of the control flow". Rust syntax constraints include two parts: ownership is immutable and modification is prohibited during borrowing, and unsafe blocks must be manually freed.

[0091] In this embodiment, the prompt word template explicitly specifies the optimization scenarios, code structure, and language constraints that need to be covered when generating test cases from a large language model, providing semantic guidance for the generation of test cases.

[0092] S130: Input the prompt word template into the large language model to generate multiple prompt words.

[0093] The computing device can input the constructed prompt word templates into a large language model. For example, the large language model can be a pre-trained language model with code generation capabilities, such as an LLaMA model or a PaLM model.

[0094] After receiving the prompt word template, the large language model combines the logical information, syntactic constraints, and test case requirements in the template to generate multiple prompt words that meet the conditions. The combinations of logical information and syntactic constraints corresponding to the multiple prompt words can be different, thereby covering a wider range of optimization scenarios or testing perspectives, and covering multiple execution paths where the target optimization pass may have vulnerabilities. For example, for the above exemplary prompt word template, the large language model may generate a prompt word that focuses on the combination of "loop unrolling threshold = 3 times" and "ownership cannot be changed and modification is prohibited during the borrowing period", while another may emphasize the combination of "constant propagation trigger condition" and "unsafe block needs to be manually released for memory", both of which meet the test case requirements of "covering loop unrolling trigger and constant propagation failure scenarios".

[0095] In some embodiments, when generating multiple prompt words, the large language model can first generate multiple scenario descriptions for different characteristic scenarios of the target optimization PASS based on the prompt word template. Each scenario description corresponds to a potential vulnerability trigger angle of the target optimization PASS, such as different loop structure scenarios, including nested loops and loops with variable iteration variables.

[0096] The large language model then transforms each scenario description into specific prompt words, clearly specifying the characteristics of the test cases, such as structural features, key variable types (e.g., specific integer types, lifecycle parameter annotations, etc.) and control flow patterns (e.g., specific branch nesting levels, loop iteration counts, etc.), as well as the Rust language version and compilation options required for the generated code.

[0097] Large language models can generate a preset number of prompt words, such as 10.

[0098] S140: Input multiple prompt words into the large language model to generate multiple initial test cases.

[0099] The large language model extracts the logical information for the target optimization pass based on the semantic description of each prompt word, and constructs a code structure that can trigger the corresponding optimization behavior. Simultaneously, it strictly adheres to the syntax constraints of the Rust language to ensure that the generated code is syntactically correct. For example, if the prompt word contains "constant propagation trigger condition," the large language model can generate code that includes runtime constant variable definitions and their references in different control flow paths; if the prompt word contains the constraint "immutable ownership, no modification during borrowing," the generated code will avoid modifying the data while the immutable borrow exists.

[0100] In this embodiment, the code generated by the large language model is referred to as the initial test case. Multiple initial test cases can cover different optimization scenarios of the target optimization pass, thereby increasing the comprehensiveness of vulnerability detection.

[0101] In some embodiments, after the computing device inputs the prompt word template into the large language model, the large language model can generate multiple prompt words and directly generate corresponding initial test cases based on these prompt words to improve testing efficiency.

[0102] As can be seen from the above technical solution, this application embodiment calls the compiler's information storage file to obtain the logical information of the target optimization PASS and the syntactic constraint information of the Rust language. Taking both indicators into account, it constructs prompt words, providing clear semantic guidance and a standardized basis for generating test cases for the large language model. The generated test cases can specifically trigger the specific optimization behaviors of the target optimization PASS, more accurately covering the vulnerabilities that the target optimization PASS may encounter during actual compilation, thus improving the relevance and effectiveness of the test cases.

[0103] Prior to step S200, a test case screening process is also included. This process filters the initial test cases to assess their validity.

[0104] Figure 3 This is a flowchart illustrating the test case selection process provided in an embodiment of this application. For example... Figure 3 As shown, the test case selection process may include the following steps S201-S204: S201: Compile multiple initial test cases using the compiler with target-optimized PASS.

[0105] The computing device can send the generated initial test cases to the Rust compiler and control the compiler to enable the target optimization PASS for compilation in order to verify whether the test cases can be compiled.

[0106] The compiler's compilation process includes the following steps: (1) Lexical analysis stage, which decomposes the source code text into a sequence of lexical units (Tokens); (2) Parsing stage, which constructs the sequence of lexical units into an Abstract Syntax Tree (AST); (3) Macro Expansion stage, which recursively expands macro calls in the AST; (4) Name Resolution stage, which resolves identifiers, module paths, and import relationships; (5) Semantic Analysis stage, which performs type inference, trait resolution, and lifetime checking; (6) High-Level Intermediate Representation (HIR) generation stage, which desugars the AST into a more regular HIR form; (7) Mid-Level Intermediate Representation (MIR) generation stage, which further lowers the HIR to a control flow graph-based form. (8) Borrow Checking phase: Non-lexical lifetime (NLL) borrow checks are performed on the MIR; (9) MIR optimization phase: Multiple MIR-level optimization passes are performed sequentially; (10) LLVM IR generation phase: The optimized MIR is translated into LLVM IR; (11) LLVM optimization phase: Multiple LLVM-level optimization passes are performed with the help of the LLVM optimization pipeline; (12) Code generation phase: The optimized LLVM IR is compiled into target machine code or other target formats (such as WebAssembly).

[0107] The computing device can detect whether the compilation was successful based on the compiled results of the mutation.

[0108] S202: In the event of compilation failure, delete the initial test cases.

[0109] The compilation failure indicates that the initial test case cannot drive the compiler to execute the target optimization PASS, is insufficient in effectiveness, and cannot detect vulnerabilities. The computing device can delete the test case.

[0110] S203: If compilation is successful, the target optimization PASS optimizes the coverage of the initial intermediate representation data of the initial test cases.

[0111] In this embodiment, the optimization coverage rate represents the proportion of the optimization path in the initial intermediate representation data during the optimization process of the target optimization PASS. The optimization path refers to the specific logical branches and operation steps traversed by the target optimization PASS when optimizing the intermediate representation data. Based on the optimized intermediate representation data, it is possible to determine which paths were actually optimized, thus obtaining the optimized paths.

[0112] The formula for calculating optimized coverage can be expressed as: Optimized coverage = Number of optimized paths of the target optimized PASS / Total number of paths of the initial intermediate representation data after optimization.

[0113] In some embodiments, the optimized path can be determined by the code corresponding to the initial intermediate representation data. That is, based on the optimized intermediate representation data, it can be determined which code is actually modified or rewritten by the target optimized PASS, and the control flow paths corresponding to these modified or rewritten codes constitute the optimized path actually covered by the PASS.

[0114] Therefore, code abstraction can be used to represent execution paths. For example, if the optimized initial intermediate representation data contains 10 lines of code, of which 3 lines are obtained by the target optimization PASS, then the total number of paths in the initial intermediate representation data can be represented as 10n, while the number of optimized paths is 3n, and the optimization coverage is 3n / 10n=30%.

[0115] Therefore, the formula for calculating optimized coverage can also be expressed as: Optimized coverage = Number of lines of code obtained after optimization by the target PASS / Total number of lines of code in the initial intermediate representation data after optimization.

[0116] Step S204: If the optimized coverage is lower than the preset threshold, the initial test cases are deleted; if the optimized coverage is higher than or equal to the preset threshold, the initial test cases are retained.

[0117] The preset threshold can be set by the tester according to the characteristics of the target PASS optimization and the test requirements, such as 20% or 30%.

[0118] For an initial test case, if its optimized coverage is greater than a preset threshold, it is determined that it has sufficient path activation capability and can effectively trigger the target optimized pass, thus possessing high testing value. Therefore, this test case can be used to detect vulnerabilities, and the computing device can retain this initial test case. Conversely, if the optimized coverage is less than or equal to the preset threshold, it indicates that the test case does not adequately cover the optimized path of the target optimized pass and may not fully expose potential vulnerabilities; in this case, the computing device can delete it.

[0119] The above screening process can significantly improve the quality of test cases, ensuring that the subsequent vulnerability detection process is more efficient and accurate.

[0120] In step S200, the vulnerability basic block is determined based on the intermediate representation data corresponding to the test case.

[0121] This application embodiment takes into account that test cases may be divided into two situations: secure code and insecure code. For secure code and insecure code, the corresponding basic blocks can be checked to see if they contain potential vulnerabilities.

[0122] Figure 4 This is a flowchart illustrating the basic block for determining vulnerabilities provided in an embodiment of this application. For example... Figure 4 As shown, step S200 may include the following steps S210-S250: S210: Detect whether the test case is safe code or unsafe code.

[0123] Secure code contains no unsafe blocks; all memory operations are performed through Rust's safe abstractions. Vulnerabilities in secure code are typically triggered by optimization passes altering the control flow structure of the secure code. Insecure code, on the other hand, contains unsafe blocks, allowing raw pointer operations, calls to unsafe external functions, etc. Vulnerabilities in secure code, besides control flow changes, may also involve optimization passes making incorrect assumptions about undefined behavior (UB), thus legitimizing code with undefined behavior.

[0124] The computing device can examine the source code of test cases to determine whether they contain the `unsafe` keyword or `unsafe` code block. If the `unsafe` keyword or `unsafe` block exists in the test case, it is determined to be unsafe code; if the `unsafe` keyword or `unsafe` block does not exist in the test case, it is determined to be safe code.

[0125] If the test case is insecure code, proceed to step S220; if the test case is secure code, proceed to step S230.

[0126] S220: Detect the basic block of the vulnerability based on preset rules, and execute step S230. The preset rules are used to characterize the conditions that trigger undefined behavior in the basic block corresponding to the insecure code.

[0127] For example, the preset rules may include a raw pointer dereference rule, which specifically detects dereference operations on raw pointers contained in basic blocks, and confirms through data flow analysis that the pointer may be in one of the following dangerous states: null pointer (i.e., a pointer with a value of 0); dangling pointer (i.e., a pointer pointing to a freed memory region); misaligned pointer (i.e., a pointer address that does not meet the alignment requirements of the type it points to); or out-of-bounds pointer.

[0128] Preset rules can include array out-of-bounds access rules, which specifically detect basic blocks containing index operations on arrays or slices where the index values ​​may exceed the valid index range of the array or slice.

[0129] The preset rules may also include illegal memory operation rules, which specifically detect calls to memory operation functions in basic blocks where the relevant parameters may violate the operation prerequisites: the source and destination memory regions must not overlap, the source and destination memory regions must not overlap, the destination pointer must be valid and aligned, and the source pointer must be valid and aligned.

[0130] The preset rules may also include detecting out-of-bounds access to unsafe block memory, overflow of iteration variables after loop unrolling, etc. These preset rules can be pre-set by the tester; this embodiment does not impose any limitations on them.

[0131] When a basic block is detected to trigger any preset rule, the computing device marks that basic block as a vulnerability candidate block.

[0132] S230: By controlling the flow graph, detect the basic block structure of intermediate representation data before and after the target optimization PASS execution optimization process.

[0133] Computing devices can extract intermediate representation data from the compiler's compilation process to optimize the target optimization pass.

[0134] The intermediate representation data optimized by the target optimization PASS can include intermediate intermediate representation data (MIR) and compiler framework intermediate representation data, where the compiler framework intermediate representation data can be LLVM IR.

[0135] MIR is an intermediate representation based on control flow graphs, organized around basic blocks. Each basic block contains several statements and a terminal instruction (such as jump, return, assertion, etc.). LLVM IR is an intermediate representation oriented towards the LLVM backend, employing a Static Single Assignment (SSA) format to further support code optimization and target code generation.

[0136] The computing device can extract the MIR control flow graphs of the corresponding functions of the test cases before and after the target optimization PASS is executed, and compare the control flow graph structures of the two MIRs, such as comparing the instruction sequence, control flow edges and termination instruction types of each basic block.

[0137] Basic blocks whose basic block structure changes are identified as vulnerable basic blocks. A change in the basic block structure indicates that the basic block is an optimization point for the target optimization pass and has potential vulnerability risk; therefore, it is marked as a vulnerable basic block.

[0138] S240: Instrument the intermediate representation data of the compiler framework and identify the basic block optimized by the target optimization PASS as the vulnerability basic block.

[0139] Computing devices can inject runtime inspection logic into the LLVM IR layer using instrumentation-based marking to determine whether the target optimization pass has performed optimization operations. For example, instrumentation can be used before or after function entry points, basic block entry points, or specific locations in the LLVM IR to record the basic blocks actually modified by the target optimization pass. Since the code logic or control flow of these basic blocks may change due to optimization, they are also marked as vulnerable basic blocks.

[0140] S250: Basic block for statistical vulnerabilities.

[0141] The computing device can count the marked vulnerability candidate blocks and perform deduplication and merging operations to ensure that each vulnerability basic block is counted only once. The counted vulnerability basic blocks cover basic blocks with potential vulnerability risks identified from different perspectives and different intermediate representation layers, providing an accurate target range for subsequent vulnerability detection.

[0142] In step S300, the test cases are sliced ​​according to the control flow characteristics of the vulnerability basic block to obtain vulnerability code fragments.

[0143] Figure 5 This is a flowchart illustrating the vulnerability code snippet extraction method provided in this application's embodiments. For example... Figure 5 As shown, step S300 may include the following steps S310-S320: S310: Detects the control flow boundaries of all vulnerable basic blocks.

[0144] In some embodiments, the computing device can analyze each vulnerable basic block in the control flow graph to determine its control flow boundary. The control flow boundary can be a specific symbol in the control flow graph, such as brackets, or an explicitly marked entry / exit node. The function of the control flow boundary is to define the scope within the control flow graph where the basic block can be analyzed independently.

[0145] In some embodiments, the computing device may perform reachability analysis on the control flow graph, including: starting from the entry basic block of the control flow graph, performing a forward traversal of the entire control flow graph to find the set of all basic blocks that can be reached by directed paths, i.e., the predecessor reachable set of the vulnerability basic block. The basic blocks in the predecessor reachable set contain the necessary condition code paths for the control execution flow to reach the vulnerability basic block, and are the key context of the vulnerability basic block. The computing device may determine the basic block in the predecessor reachable set that is closest to the vulnerability basic block as the control flow boundary.

[0146] S320: Based on the control flow boundary, context slicing is performed on the basic vulnerable block to obtain the vulnerable code fragment.

[0147] The computing device can obtain the mapping relationship between basic blocks in the intermediate representation data and source code (i.e., test case) line numbers. Based on this mapping relationship, all basic blocks within the control flow boundary are reverse-mapped to the corresponding source code lines of the original test cases.

[0148] Computing devices can extract code snippets corresponding to these lines of source code, thereby enabling context slicing.

[0149] As can be seen from the above technical solution, this application embodiment utilizes the control flow boundary of the vulnerability basic block to extract code fragments containing the vulnerability basic block and its necessary context from the original test cases, i.e., vulnerability code fragments. Context slicing retains the key control flow path and related data traversed from the program entry point to the vulnerability basic block, and removes code interference unrelated to the vulnerability basic block, making the subsequently generated initial seed more targeted.

[0150] In step S400, an initial seed is generated based on the vulnerable code snippet.

[0151] The initial seeds are fuzzing inputs whose execution paths can reach the vulnerability's basic block. This application uses a vulnerable code snippet as a template to generate multiple initial seeds whose execution paths can reach the vulnerability's basic block. The number of initial seeds can be preset; for example, five initial seeds can be generated for each vulnerable code snippet.

[0152] The computing device can use a large model to generate the initial seed. The large model can be a pre-trained language model with code generation capabilities, such as the GPT series model or the LLaMA series model.

[0153] The computing device can combine natural language descriptions of the basic characteristics of the vulnerability to construct a new round of hints, and input the hints and vulnerability code fragments into a large model so that the large model can generate an initial seed.

[0154] In step S500, a directional fuzzy test is performed on the target optimization PASS based on the initial seed.

[0155] Figure 6 This is a schematic diagram of the targeted fuzz testing process provided in an embodiment of this application. For example... Figure 6 As shown, step S500 may include the following steps S510-S520: S510: Construct a seed queue based on the initial seed. The seed queue can be divided into three priorities: high-priority seeds, medium-priority seeds, and low-priority seeds. High-priority seeds are the initial seeds with the shortest target distance, meaning the execution path is closest to the vulnerability's basic block in the control flow graph. Medium-priority seeds are the initial seeds with the highest optimization path coverage, meaning they can cover more optimization paths that pass the target's optimization. Low-priority seeds are all other seeds besides the high-priority and medium-priority seeds.

[0156] When constructing the seed queue, the computing device can calculate the target distance from each initial seed to the vulnerability base block and the optimized path coverage. The target distance can be represented by the number of edges in the execution path from the seed entry point to the vulnerability base block in the control flow graph.

[0157] Optimized path coverage represents the proportion of optimized paths in the execution path from the initial seed to the vulnerability base block, where the target optimized pass executes the optimization process. The computing device can obtain the total execution path from the initial seed to the vulnerability base block, identify all optimized paths actually triggered by the target optimized pass within the total execution path, and calculate the proportion of these optimized paths in the total execution path. This can be calculated as the ratio of the number of optimized paths to the total number of execution paths.

[0158] In some embodiments, considering that the execution path can be determined by code, the computing device can obtain the number of lines of code corresponding to the total execution path from the initial seed to the vulnerability basic block, and the number of lines of code corresponding to the optimized path actually triggered by the target optimized PASS. The computing device can calculate the ratio of the number of lines of code corresponding to the optimized path to the total number of lines of code corresponding to the total execution path to obtain the optimized path coverage.

[0159] When constructing the seed queue, the computing device can select a preset number of initial seeds with the shortest target distance as high-priority seeds. For example, it can select the top 3 initial seeds with the shortest target distance as high-priority seeds, or it can select the top 20% of the initial seeds with the shortest target distance as high-priority seeds.

[0160] A shorter target distance means that the seed will reach the vulnerability base block faster, which means the vulnerability will be triggered faster and testing efficiency can be improved.

[0161] After selecting high-priority seeds, medium-priority seeds are chosen from the remaining seeds; these are the preset number of initial seeds with the highest optimization path coverage. The number of medium-priority seeds can be the same as or different from the number of high-priority seeds; this embodiment does not impose any limitations. Medium-priority seeds have high optimization path coverage because they cover more critical paths where the target passes, thus exposing potential defects in the optimization stage more efficiently.

[0162] After filtering out high- and medium-priority seeds, the remaining seeds are designated as low-priority seeds.

[0163] S520: Select initial seeds sequentially according to the priority order of the seed queue to perform directional fuzzy testing on the target optimization PASS.

[0164] Directed fuzz testing selects seeds from the seed queue in the order of high priority → medium priority → low priority as the current test input, triggering the target optimization PASS execution, thus realizing the directed fuzz testing process.

[0165] Targeted fuzzing can be performed using fuzzing frameworks such as AFL++, libFuzzer, and Honggfuzz. The results of targeted fuzzing fall into two categories: either no vulnerability is detected and the program runs normally, or the vulnerability is successfully triggered, manifesting as program crashes, assertion failures, or undefined behavior.

[0166] In step S600, if the test results indicate that no vulnerabilities are found, it means that the target optimized PASS has not exposed any security flaws within the current test coverage. However, this does not mean that the PASS is absolutely secure, so vulnerability testing can continue. The computing device can update the initial seed, dynamically expand the seed queue, and perform vulnerability testing again. The computing device can calculate the target distance and optimized path coverage of the initial seed, filter the initial seed, and perform mutation updates.

[0167] Figure 7 This is a schematic diagram illustrating the initial seed selection and mutation update process provided in an embodiment of this application. For example... Figure 7 As shown, step S600 may include the following steps S610-S630: S610: Calculate the weighted score of the target distance and the optimized path coverage based on the preset weight coefficients to obtain the weighted score of the initial seed.

[0168] For each initial seed in the seed queue, after directional fuzzy testing, its target distance (dist) and optimized path coverage (cov) are calculated. These are then weighted and aggregated according to preset weighting coefficients to obtain the weighted score for that initial seed. The formula for calculating the weighted score is as follows: score = w1 × dist + w2 × cov Where w1 and w2 are preset weight coefficients, satisfying w1+w2=1, w1≥0, w2≥0. For example, w1 is set to 0.6 and w2 is set to 0.4.

[0169] S620: Select the initial seed of the target based on the weighted score, and update the initial seed of the target by mutation.

[0170] The computing device can select the top N seeds with the highest weighted scores as the target initial seeds, where N is a preset number, for example, N=3. Then, a mutation update is performed on the target initial seeds to generate new target initial seeds; that is, the mutation update is used to increase the number of target initial seeds.

[0171] The mutation update operation can include byte-level mutation, lexical-level mutation, syntactic structure mutation, and semantic-aware mutation, etc., and the specific mutation operation is not limited in the embodiments of this application. The output goal of the mutation update is to increase the number of target initial seeds and expand the number of seeds. In one round of mutation, each target initial seed can generate dozens to hundreds of variant seeds, and the specific number is not limited.

[0172] S630: Use the mutated and updated target initial seed as the new initial seed, and return to the step of performing directional fuzz testing on the target PASS optimization based on the initial seed.

[0173] The newly generated seed is added to the seed queue, and step S500 is retried to continue targeted fuzz testing on the target optimized PASS with the new seed set, forming a continuous iteration of "test-evaluate-mutate-retest" until the vulnerability is detected.

[0174] During the continuous iteration process, the overall quality of the seed queue continuously improves with the increase of iteration rounds, the average target distance gradually decreases, indicating that the seed is getting closer and closer to the basic vulnerability block, and the average optimized path coverage gradually increases, indicating that the seed's coverage of the target optimization pass is becoming more and more comprehensive, thus improving the accuracy and efficiency of vulnerability detection.

[0175] In some embodiments, if the test results indicate that no vulnerability exists, step S601 is also included.

[0176] S601: Detects the duration of the timer.

[0177] For a continuous iterative process, a detection duration can be preset, referred to as the duration threshold in this embodiment. When the timer reaches the threshold, the system automatically terminates the iteration process and determines that the current target optimization PASS has not detected any vulnerabilities.

[0178] The timer starts counting after the initial seed is generated. If the timeout period reaches a threshold, the directional fuzzy test for the target optimization PASS is stopped. If the timeout period does not reach the threshold, the steps of calculating the target distance and optimized path coverage of the initial seed are executed, i.e., step S610.

[0179] In some embodiments, an upper limit for the number of iteration rounds can be preset. When the preset upper limit is reached, the system also terminates the testing process and determines that the current target optimization pass has not detected any vulnerabilities.

[0180] In step S700, if the test results indicate the existence of a vulnerability, the vulnerability triggered by the initial seed is determined.

[0181] If, during targeted fuzzing, an initial seed input to the compiler causes the compiler to crash, assertion to fail, exhibit undefined behavior, or generate incorrect code, the test results indicate the presence of a vulnerability. This application's embodiments record the content of the initial seed that triggers the vulnerability, the corresponding target optimization pass name, the location of the vulnerability's basic block, and the vulnerability information triggered by the initial seed, thereby achieving vulnerability detection.

[0182] Corresponding to the embodiments of the aforementioned vulnerability detection methods, this application also provides embodiments of an operator testing apparatus.

[0183] Figure 8 This is a schematic diagram of a vulnerability detection system provided in an embodiment of this application.

[0184] like Figure 8 As shown, the vulnerability detection system 800 may include a test case generation module 810, a vulnerability basic block determination module 820, a code slicing module 830, a seed generation module 840, a fuzz testing module 850, a seed update module 860, and a vulnerability determination module 870.

[0185] Test case generation module 810 is used to generate test cases based on the compiler's target optimization PASS; The vulnerability base block determination module 820 is used to determine the vulnerability base block based on the intermediate representation data corresponding to the test case; wherein, the intermediate representation data is obtained by compiling the test case by the compiler; the vulnerability base block is the base block in the test case where the potential vulnerability is located; The code slicing module 830 is used to slice test cases based on the control flow characteristics of the vulnerability basic block to obtain vulnerability code fragments; Seed generation module 840 is used to generate an initial seed based on a vulnerability code snippet; Fuzzy testing module 850 is used to perform directional fuzzy testing on the target optimization PASS based on the initial seed; The seed update module 860 is used to calculate the target distance and optimized path coverage of the initial seed when the test results indicate that there is no vulnerability; to filter the initial seed based on the target distance and optimized path coverage, and to perform mutation update on the filtered initial seed; where the target distance represents the distance from the initial seed to the vulnerability basic block, and the optimized path coverage represents the proportion of the optimized path in the target optimization PASS execution optimization process in the execution path from the initial seed to the vulnerability basic block; The vulnerability determination module 870 is used to determine the vulnerability triggered by the initial seed when the test results indicate the existence of a vulnerability.

[0186] Figure 9 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0187] like Figure 9 As shown, the computing device 900 includes a processor 901 and a memory 902. Exemplarily, the computing device 900 may also include a communications interface 903 and a communications bus 904.

[0188] The processor 901, memory 902, and communication interface 903 communicate with each other via communication bus 904. The communication interface 903 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0189] In some embodiments, the processor 901 is used to execute program 905, which specifically performs the relevant steps in the above-described vulnerability detection method embodiments. Specifically, program 905 may include program code, which includes computer-executable instructions.

[0190] For example, processor 901 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 900 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0191] In some embodiments, memory 902 is used to store program 905. Memory 902 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0192] Specifically, program 905 can be called by processor 901 to cause computing device 900 to perform the method operations described in the above embodiments.

[0193] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 900, causes the computing device 900 to perform the vulnerability detection method described in the above embodiments.

[0194] The executable instructions can be used to cause the computing device 900 to perform vulnerability detection methods.

[0195] For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0196] This application provides a chip device in some embodiments, which is applied to a server. The chip device includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs various steps in the vulnerability detection method shown in the above-described method embodiments.

[0197] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding vulnerability detection methods provided above, and will not be repeated here.

[0198] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0199] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0200] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution apparatus, device, or equipment (such as a computer-based device, a processor-included device, or other device that can fetch and execute instructions from, an instruction execution apparatus, device, or equipment).

[0201] For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution means, apparatus, or device.

[0202] More specific examples of computer-readable media (a non-exhaustive list) include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0203] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0204] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A vulnerability detection method, characterized in that, The method includes: Optimize PASS to generate test cases according to the compiler's objectives; Based on the intermediate representation data corresponding to the test cases, the vulnerability basic blocks are determined; the intermediate representation data is obtained by compiling the test cases using the compiler; the vulnerability basic blocks are the basic blocks in the test cases where potential vulnerabilities are located. Based on the control flow characteristics of the basic vulnerability block, the test case is sliced ​​to obtain the vulnerability code fragment; An initial seed is generated based on the vulnerability code snippet; Based on the initial seed, perform a directional fuzzy test on the target optimized PASS; If the test results indicate that no vulnerability exists, calculate the target distance and optimized path coverage of the initial seed; filter the initial seed based on the target distance and optimized path coverage, and perform mutation update on the filtered initial seed; the target distance represents the distance from the initial seed to the vulnerability block, and the optimized path coverage represents the proportion of the optimized path of the target optimized PASS execution optimization process in the execution path of the initial seed to the vulnerability block; If the test results indicate the presence of a vulnerability, the vulnerability triggered by the initial seed is determined.

2. The method according to claim 1, characterized in that, The process of optimizing PASS to generate test cases according to the compiler's target includes: Based on the compiler's information storage file, obtain the logical information of the target optimization PASS and the syntactic constraint information of the RUST language; Construct a prompt word template based on the logical information and the grammatical constraint information; The prompt word template is input into the large language model to generate multiple prompt words; The multiple prompt words are input into the large language model to generate multiple initial test cases.

3. The method according to claim 2, characterized in that, Before determining the basic vulnerability block based on the intermediate representation data corresponding to the test case, the process also includes: The compiler is used to optimize PASS with the target, and multiple initial test cases are compiled. If compilation fails, delete the initial test cases. If compilation is successful, the optimization coverage of the target optimization PASS on the initial intermediate representation data of the initial test case is detected; the optimization coverage represents the proportion of the optimization path of the target optimization PASS in the initial intermediate representation data; if the optimization coverage is lower than a preset threshold, the initial test case is deleted; if the optimization coverage is higher than or equal to the preset threshold, the initial test case is retained.

4. The method according to any one of claims 1 to 3, characterized in that, The intermediate representation data includes mid-level intermediate representation data and compiler framework intermediate representation data; the determination of vulnerability basic blocks based on the intermediate representation data corresponding to the test cases includes: When the test case is secure code, the basic block structure of the intermediate representation data before and after the target optimization PASS execution optimization process is detected by the control flow graph. The basic blocks whose basic block structure changes are identified as the vulnerable basic blocks; Instrumentation is performed on the intermediate representation data of the compiler framework, and the basic block optimized by the target optimization PASS is determined as the vulnerability basic block.

5. The method according to any one of claims 1 to 3, characterized in that, The intermediate representation data includes mid-level intermediate representation data and compiler framework intermediate representation data; the determination of vulnerability basic blocks based on the intermediate representation data corresponding to the test cases includes: When the test case is insecure code, the vulnerability basic block is detected based on preset rules; the preset rules are used to characterize the conditions that trigger undefined behavior in the basic block corresponding to the insecure code. By using the control flow graph, the basic block structure of the intermediate representation data before and after the target optimization PASS execution optimization process is detected; The basic blocks whose basic block structure changes are identified as the vulnerable basic blocks; Instrumentation is performed on the intermediate representation data of the compiler framework, and the basic block optimized by the target optimization PASS is determined as the vulnerability basic block.

6. The method according to claim 4 or 5, characterized in that, The step of slicing the test case based on the control flow characteristics of the vulnerability's basic block to obtain vulnerable code fragments includes: Detect the control flow boundaries of all the aforementioned vulnerability basic blocks; Based on the control flow boundary, the vulnerability basic block is sliced ​​into context to obtain the vulnerability code fragment.

7. The method according to any one of claims 1 to 6, characterized in that, The targeted fuzzy test of optimizing the target PASS based on the initial seed includes: A seed queue is constructed based on the initial seed; the seed queue is divided into high-priority seeds, medium-priority seeds and low-priority seeds; wherein, the high-priority seed is the initial seed with the shortest target distance, the medium-priority seed is the initial seed with the highest optimized path coverage, and the low-priority seed is the initial seed other than the high-priority seed and the medium-priority seed. According to the priority order of the seed queue, initial seeds are selected in turn to perform targeted fuzzy testing on the target optimization PASS.

8. The method according to any one of claims 1 to 7, characterized in that, The step of filtering the initial seed based on the target distance and the optimized path coverage, and then updating the filtered initial seed through mutation, includes: The weighted score of the initial seed is obtained by calculating a weighted score between the target distance and the optimized path coverage based on a preset weighting coefficient. The target initial seed is selected based on the weighted score, and the target initial seed is then mutated and updated; the mutation and update are used to increase the number of target initial seeds. The mutated and updated target initial seed is used as the new initial seed, and the process returns to the step of performing targeted fuzz testing on the target PASS optimization based on the initial seed.

9. The method according to any one of claims 1 to 8, characterized in that, If the test results indicate that no vulnerabilities exist, the following are also included: The timing duration of the detection timer is determined; the timer starts timing after the initial seed is generated. If the timeout period reaches the timeout threshold, stop the targeted fuzzy test for the target optimized PASS. If the timeout period does not reach the timeout threshold, the steps of calculating the target distance and optimized path coverage of the initial seed are performed.

10. A computing device, characterized in that, The computing device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the computing device to perform the vulnerability detection method as described in any one of claims 1 to 9.

Images