Fuzz testing method and device for operating system kernel data race

Abstract

The application provides a kind of fuzz testing method and device for operating system kernel data competition, belong to computer software testing technical field.Method includes: with the operating system to be tested as target kernel, generate the kernel image of the target kernel;Single-thread fuzz testing is carried out on the kernel image, and single-thread execution result is obtained;According to the single-thread execution result, obtain basic corpus;According to the basic corpus, concurrent fuzz testing is carried out on the kernel image, and concurrent execution result is obtained;According to the concurrent execution result, determine concurrent corpus, and the race adjacent access pair is included in the concurrent corpus;According to the race adjacent access pair, obtain the data competition test result of the target kernel.Can improve the efficiency and accuracy of operating system kernel data competition test, enhance the reliability of test result.

Description

Technical Field

[0001] This application belongs to the field of computer software testing technology, specifically relating to a fuzzing test method and apparatus for data contention in the operating system kernel. Background Technology

[0002] In the development and testing of operating system kernels, data races are a problem that is very easy to occur and difficult to detect in concurrent scenarios. They can lead to abnormal kernel operation results, system crashes, and even security vulnerabilities. Therefore, detection and testing technologies for kernel data races have become a core part of kernel security assurance.

[0003] Currently, the industry mostly uses fuzz testing to detect data contention in operating system kernels, but existing technical solutions have many significant drawbacks in practical applications. This includes a lack of targeted kernel processing in the early stages of testing, making it difficult to effectively capture concurrent interaction signals during runtime and resulting in insufficient observability of potential data races; the lack of effective guidance in corpus construction during the single-threaded testing phase, leading to inconsistent quality of generated basic test inputs and low branch coverage, which creates numerous hidden dangers of invalid execution for subsequent concurrent testing; the concurrency testing phase often involves simply splicing single-threaded programs without proper pairing and screening, resulting in a large and highly arbitrary combination space for program pairs, making it difficult to trigger effective cross-program concurrent interaction, and consuming a large amount of computational resources in meaningless program pairing execution; at the same time, the results of concurrent execution are mixed with a large amount of noise signals that can be interpreted by single threads, making it impossible to effectively extract true concurrent interaction-related clues, resulting in a lack of targeted test feedback and difficulty in driving the optimization and evolution of subsequent test cases; in addition, there is a lack of stable reproduction and verification mechanisms for suspected data race clues discovered during testing, and the reproduction rate of clues is low due to factors such as scheduling randomness and environmental jitter, making it difficult to transform suspected clues into high-confidence effective test results. The overall testing process suffers from problems such as blind exploration, low output efficiency, and poor result reliability, making it unable to efficiently and accurately detect potential data race issues in the operating system kernel. Summary of the Invention

[0004] This application provides a fuzz testing method and apparatus for operating system kernel data contention. By accurately capturing concurrent interaction clues related to data contention in the kernel, it significantly improves the efficiency and accuracy of operating system kernel data contention testing and enhances the reliability of test results.

[0005] This application provides a fuzzing method for data contention in an operating system kernel, comprising: using the operating system to be tested as the target kernel, generating a kernel image of the target kernel, performing a single-threaded fuzzing test on the kernel image to obtain a single-threaded execution result; obtaining a basic corpus based on the single-threaded execution result; performing a concurrent fuzzing test on the kernel image based on the basic corpus to obtain a concurrent execution result; determining a concurrent corpus based on the concurrent execution result, wherein the concurrent corpus includes race condition proximity access pairs; wherein the race condition proximity access pair includes a first memory access operation and a second memory access operation, the first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap, and the access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation; and obtaining the data contention test result of the target kernel based on the race condition proximity access pair.

[0006] According to the fuzzing method for data races in the operating system kernel provided in this application, generating the kernel image of the target kernel includes: determining an initial taint source based on the kernel functions of the target kernel; determining the taint variable propagation path of the initial taint source based on the function control flow graph of the kernel functions; marking access instructions involving tainted variables as candidate shared access points based on the taint variable propagation path; inserting monitoring code into the candidate shared access points under the kernel compilation framework to which the target kernel belongs to obtain reference kernel code; and generating the kernel image of the target kernel based on the reference kernel code.

[0007] According to the fuzzing method for operating system kernel data contention provided in this application, the step of performing single-threaded fuzzing on the kernel image to obtain single-threaded execution results includes: obtaining an initial test corpus set; obtaining initial test data based on the initial test corpus set; and performing single-threaded fuzzing on the kernel image based on the initial test data to obtain single-threaded execution results. The single-threaded fuzzing includes the following steps: performing single-threaded fuzzing on the kernel image for each initial test data to obtain the code branch triggered by each initial test data; and obtaining the corresponding code branch for each initial test data based on the code branch triggered by each initial test data. The branch coverage gain is included in the single-threaded execution result. The step of obtaining the basic corpus based on the single-threaded execution result includes: determining the target test corpus based on the branch coverage gain; generating new test corpus based on the target test corpus; updating the initial test corpus based on the new test corpus; repeatedly executing the single-threaded fuzz test on the kernel image based on the initial test corpus to obtain the single-threaded execution result of each single-threaded fuzz test, until the branch coverage gain included in the single-threaded execution result reaches a preset value; and obtaining the basic corpus based on the target test corpus at the time of the last execution of the single-threaded fuzz test.

[0008] According to the fuzzing method for data contention in the operating system kernel provided in this application, the step of performing concurrent fuzzing on the kernel image based on the basic corpus to obtain concurrent execution results includes: initializing a candidate program pool based on the basic corpus; selecting a main program from the candidate program pool based on historical test data, wherein the historical test data includes test data generated based on the coverage of newly added branches and the coverage of newly added race-proximity access pairs included in each candidate program pair; selecting a partner program from the candidate program pool based on the main program to obtain a candidate program pair; allocating a first thread to the main program in the candidate program pair and a second thread to the partner program in the candidate program pair; concurrently executing the first thread and the second thread to obtain the common branch coverage, race-proximity access pairs, the coverage of the race-proximity access pairs, and a concurrent candidate pair set, wherein the concurrent candidate pair set includes the execution records of each concurrent execution of the candidate program pair; the step of performing concurrent fuzzing on the kernel image based on the basic corpus to obtain concurrent execution results includes: initializing a candidate program pool based on the basic corpus; selecting a main program from the candidate program pool based on historical test data, wherein the historical test data includes test data generated based on the newly added branch coverage and the coverage of newly added race-proximity access pairs included in each candidate program pair to obtain concurrent execution results; the step of performing concurrent fuzzing on the kernel image based on the basic corpus to obtain concurrent execution results includes: initializing a candidate program pool based on the basic corpus; selecting a main program from the candidate program pool based on historical test data, wherein the historical test data includes test data generated ... The concurrent execution results are used to determine the concurrent corpus, including: performing the following operations for each candidate program pair: independently executing the main program and partner program of the current candidate program pair multiple times in a single-threaded environment to obtain the first branch coverage of the main program, the second branch coverage of the partner program, and a single-threaded candidate pair set, wherein the single-threaded candidate pair set includes the execution records of each independent execution of the current candidate program pair; determining the concurrent branch coverage increment based on the common branch coverage of the current candidate program pair and the first branch coverage and the second branch coverage; determining whether the current candidate program pair includes the newly added branch coverage and the newly added race-proximity access pair coverage by using the first branch coverage, the second branch coverage, the single-threaded candidate pair set, the concurrent branch coverage increment, the coverage of the race-proximity access pair, and the concurrent candidate pair set; if so, determining the current candidate program pair as the target candidate program pair; and determining the concurrent corpus based on the target candidate program pair.

[0009] According to the fuzzing method for data contention in the operating system kernel provided in this application, the step of selecting the main program from the candidate program pool based on historical test data includes: initializing a set of distribution parameters for each initialization candidate program in the initialization candidate program pool, wherein the distribution parameters are updated according to whether the main program generates new interactive data in subsequent concurrent execution; sampling each initialization candidate program based on its corresponding distribution parameters to obtain a sampled value; and determining the initialization candidate program with the largest sampled value among multiple initialization candidate programs as the main program.

[0010] According to the fuzzing method for data contention in the operating system kernel provided in this application, the step of selecting a partner program for the main program from the candidate program pool based on the main program includes: determining the number of concurrent executions and the number of effective outputs for each candidate program in the candidate program pool during historical concurrent execution, wherein effective outputs indicate that the candidate program has new interactive data; calculating the affinity between each main program and other candidate programs in the candidate program pool based on the number of concurrent executions and the number of effective outputs; obtaining multiple reference partner programs for each main program from the candidate program pool; determining the combination score of each reference program pair based on the affinity, wherein the reference program pair includes one main program and one reference partner program; and determining the partner program for each main program based on the combination score.

[0011] According to the fuzzing method for data contention in the operating system kernel provided in this application, the step of obtaining the data contention test result of the target kernel based on the race-proximity access pair includes: obtaining race-proximity access pairs from the concurrent corpus; performing multiple rounds of repeated concurrent tests on the race-proximity access pairs to obtain a multi-round test result set; obtaining stably triggered reference race-proximity access pairs based on the multi-round test result set to obtain a reference race-proximity access pair set; performing controlled verification operation on the reference race-proximity access pair set to obtain a contention test result; and persistently storing the reference race-proximity access pair when the contention test result indicates that the reference race-proximity access pair is the target race-proximity access pair.

[0012] According to the fuzzing method for data contention in the operating system kernel provided in this application, the step of performing multiple rounds of repeated concurrent testing on the race condition proximity access pair to obtain a multi-round test result set includes: generating a test environment for the race condition proximity access pair through state restoration and virtual machine snapshots; performing multiple rounds of repeated concurrent testing on the entry to be verified in the test environment to obtain a multi-round test result set; and obtaining a stably triggered reference race condition proximity access pair based on the multi-round test result set includes: obtaining the number of times the same race condition proximity access pair appears in the multi-round test result set; and obtaining a stably triggered reference race condition proximity access pair based on the number of occurrences.

[0013] According to the fuzzing method for operating system kernel data contention provided in this application, the controlled verification run on the reference race condition neighbor access pair set to obtain the contention test results includes: obtaining historical contention test results for each reference race condition neighbor access pair in the reference race condition neighbor access pair set; determining the verification skip probability of each reference race condition neighbor access pair based on the historical contention test results; obtaining the category of each reference race condition neighbor access pair; determining a verification scheduling strategy based on the category; determining the current reference race condition neighbor access pair based on the verification skip probability of each reference race condition neighbor access pair and the verification scheduling strategy; performing the following operations for each reference race condition neighbor access pair in the reference race condition neighbor access pair set: performing state restoration for the current verification round to obtain a target state; determining a delay control strategy for the current reference race condition neighbor access pair based on the timing characteristics of the current reference race condition neighbor access pair, the delay control including startup delay and / or access delay; and in the target state, executing the program pair and barrier concurrency configuration corresponding to the current reference race condition neighbor access pair according to the delay control strategy to obtain the contention test results.

[0014] This application also provides a fuzzing device for data contention in an operating system kernel, comprising: a generation unit for generating a kernel image of the target kernel, using the operating system to be tested as the target kernel; a first testing unit for performing a single-threaded fuzzing test on the kernel image to obtain a single-threaded execution result; a first acquisition unit for acquiring a basic corpus based on the single-threaded execution result; a second testing unit for performing a concurrent fuzzing test on the kernel image based on the basic corpus to obtain a concurrent execution result; a determination unit for determining a concurrent corpus based on the concurrent execution result, wherein the concurrent corpus includes race-proximity access pairs; wherein the race-proximity access pairs include a first memory access operation and a second memory access operation, the first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap, and the access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation; and a second acquisition unit for acquiring the data contention test result of the target kernel based on the race-proximity access pairs.

[0015] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the fuzzing method for data races against the operating system kernel as described above.

[0016] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the fuzzing method for data contention in the operating system kernel as described above.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the fuzzing method for data contention in the operating system kernel as described above.

[0018] According to the fuzzing method and apparatus for data contention in the operating system kernel provided in this application, a high-quality basic corpus is first generated specifically for the target kernel image, and then a high-quality basic corpus is built through single-threaded fuzzing. Subsequently, concurrent fuzzing is carried out based on this corpus to extract race-state proximity access pairs to build a concurrent corpus. Finally, a layered testing process is used to obtain data contention test results based on race-state proximity access pairs. This progressively improves the effectiveness of test input, reduces the blindness of concurrent testing, and accurately captures concurrent interaction clues related to data contention in the kernel. As a result, the efficiency and accuracy of operating system kernel data contention testing are greatly improved, and the reliability of test results is enhanced. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is one of the flowcharts of the fuzzing method for data contention in the operating system kernel provided in this application.

[0021] Figure 2 This is a schematic diagram illustrating the definition of race-state proximity access pairs provided in this application.

[0022] Figure 3 This is a schematic diagram illustrating the generation and mutation of the candidate program pairs provided in this application.

[0023] Figure 4 This is a schematic diagram of the collection and confirmation process for competitive proximity access pairs during the verification phase provided in this application.

[0024] Figure 5 This is the second flowchart of the fuzzing method for data contention in the operating system kernel provided in this application.

[0025] Figure 6 This is a block diagram of the functional units of the fuzzing device for data contention in the operating system kernel provided in this application.

[0026] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0029] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0030] Currently, when using fuzz testing to detect kernel data races in the industry, there are several problems: the kernel lacks targeted processing in the early stages of testing, resulting in insufficient observation of concurrent interaction signals and potential data races; the construction of single-threaded test corpora lacks effective guidance, leading to low quality of basic input and low branch coverage; the pairing of concurrent test programs is blind and inefficient; the concurrent execution results are noisy and lack targeted feedback; and there is no stable mechanism for reproducing and verifying suspected data race clues. The overall testing process is characterized by blind exploration, low output efficiency, and poor reliability of results, making it impossible to efficiently and accurately detect potential kernel data races.

[0031] To address the aforementioned problems, this application provides a fuzzing method and apparatus for fuzzing data contention in the operating system kernel. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0032] Please see Figure 1 The fuzzing method for data contention in the operating system kernel includes the following steps.

[0033] S101 generates a kernel image of the target kernel using the operating system to be tested as the target kernel.

[0034] The target kernel can be any operating system kernel or its submodules subject to data contention testing. It is the core object of this solution's full-process fuzzing, with all test operations and signal acquisition revolving around this target kernel. Specific kernels or submodules can be selected as the testing object based on actual testing needs. The kernel image is a bootable kernel compilation product obtained from the target kernel source code after static auxiliary screening and code instrumentation. It serves as the foundation for subsequent single-threaded and concurrent fuzzing tests.

[0035] S102 performs a single-threaded fuzz test on the kernel image to obtain the single-threaded execution result.

[0036] Among them, the single-threaded fuzzing is a fuzzing operation carried out in a single-threaded environment around the target kernel image. During the execution process, a dedicated single-threaded execution module is responsible for running various test inputs. The entire process relies on the single-threaded execution context to complete the triggering and execution of test cases, which can effectively avoid the execution interference caused by multi-threaded concurrency and focus on the separate exploration of the target kernel code path.

[0037] S103, obtain the basic corpus based on the single-thread execution result.

[0038] The basic corpus is a collection of high-value test data formed by filtering and integrating execution data from single-threaded fuzzing. It can use the branch coverage gain in the single-threaded execution results as the core filtering metric to extract all target test data corresponding to when the branch coverage gain reaches a preset value after multiple rounds of single-threaded fuzzing. These test data serve as the core components of the basic corpus. Alternatively, the target test data can be further classified and organized based on the code branch information triggered by each test data point in the single-threaded execution results, making the structure of the basic corpus more suitable for subsequent testing needs. The basic corpus can contain various filtered single-threaded test cases with high branch coverage, as well as related contextual information such as code branch triggering information and branch coverage gain data for each test case.

[0039] S104, based on the basic corpus, performs concurrent fuzz testing on the kernel image to obtain concurrent execution results.

[0040] Concurrent fuzzing is a multi-threaded collaborative testing operation based on a corpus with high branch coverage. The concurrent execution result is the complete set of runtime data obtained after concurrent fuzzing of the candidate program. This may include the common branch coverage formed during concurrent execution, reflecting the program's exploration effect on the target kernel code path through collaborative execution; race-proximal pairs (RPPs) captured during execution and their corresponding coverage, characterizing the amount of new candidate pair information brought about by concurrent interactions; and a set of concurrent candidate pairs, recording the complete execution records of each concurrent execution of the candidate program, which intuitively reflects the concurrent execution state of the program pair.

[0041] S105, determine the concurrent corpus based on the concurrent execution results, the concurrent corpus includes race-state neighbor access pairs.

[0042] Among them, the race-proximity access pair includes a first memory access operation and a second memory access operation. The first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap. The access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation.

[0043] For example Figure 2 As shown, two memory access operations were observed on different execution threads, namely thread A (the first thread) and thread B (the second thread). and A pair is considered a race-nearest neighbor pair if and only if the following conditions are met: First, and The events occurred in different threads; secondly, the memory regions accessed by the two operations overlapped; thirdly, the time difference between the two operations was within a preset threshold range, thus falling into the same race condition window; fourthly, and At least one of them is a write operation. Based on three criteria—time proximity, address overlap, and write participation—this scheme unifies access behaviors that may cause data contention into statistically significant and deduplicatable candidate pairs, providing a consistent signal representation and processing object for subsequent coverage measurement, candidate screening, and offline verification.

[0044] S106, based on the race-proximity access test results, obtain the data competition test results of the target kernel.

[0045] As can be seen, this embodiment first generates a targeted kernel image, then constructs a high-quality basic corpus through single-threaded fuzz testing, subsequently conducts concurrent fuzz testing based on this corpus and extracts race-proximity access pairs to construct a concurrent corpus, and finally obtains data competition test results based on race-proximity access pairs. This hierarchical testing process progressively improves the effectiveness of test input, reduces the blindness of concurrent testing, and accurately captures concurrent interaction clues related to data competition in the kernel, thereby significantly improving the efficiency and accuracy of operating system kernel data competition testing and enhancing the reliability of test results.

[0046] In one possible embodiment, generating a kernel image of the target kernel includes: determining initial taint sources based on kernel functions of the target kernel; determining taint variable propagation paths of the initial taint sources based on the function control flow graph of the kernel functions; marking access instructions involving tainted variables as candidate shared access points based on the taint variable propagation paths; inserting monitoring code into the candidate shared access points within the kernel compilation framework to which the target kernel belongs, thereby obtaining reference kernel code; and generating a kernel image of the target kernel based on the reference kernel code.

[0047] When determining the initial taint sources, one can directly select visible global variables, cross-thread shared memory objects, and function parameters from the target kernel's kernel functions as initial taint sources. Alternatively, the selection range of initial taint sources can be appropriately adjusted according to the actual testing requirements of the target kernel to ensure that the taint sources can cover the core shared data areas in the kernel.

[0048] When determining the propagation path of tainted variables, the function control flow graph of the kernel function can be used. Starting from the selected initial taint source, the entire chain of tainted variable propagation and usage can be traversed along the function's execution logic, clearly tracing the flow trajectory of the tainted variable in the target kernel source code. By traversing each node and edge of the control flow graph, every execution step involved by the tainted variable can be marked, ensuring that no propagation path of the tainted variable is missed, making subsequent access instruction marking more targeted. After obtaining the complete tainted variable propagation path, all memory access instructions involving the tainted variable in the path can be marked as candidate shared access points.

[0049] After marking candidate shared access points, monitoring code can be uniformly inserted into all marked candidate shared access points within the kernel compilation framework of the target kernel. This monitoring code can be configured to record key information about memory access events, specifically including variable identifiers, access addresses or access ranges, access types, time information, and thread identifiers. The types of information recorded by the monitoring code can also be flexibly expanded according to signal acquisition requirements. The kernel source code after inserting the monitoring code becomes the reference kernel code, which retains the original functionality of the target kernel while adding the ability to acquire runtime event signals.

[0050] Finally, the compilation process of the target kernel can be completed directly based on the reference kernel code. The compiled products can also be linked with custom modules to generate a bootable target kernel image. This kernel image can run stably in subsequent single-threaded and concurrent fuzz tests, and can output memory access event signals collected by the monitoring code in real time during the operation, providing continuous signal support for identifying race-proximity access pairs and capturing concurrent interaction clues in subsequent stages.

[0051] In one possible embodiment, performing a single-threaded fuzz test on the kernel image to obtain a single-threaded execution result includes: obtaining an initial test corpus set; obtaining initial test corpora based on the initial test corpus set; performing a single-threaded fuzz test on the kernel image based on the initial test corpora to obtain a single-threaded execution result. The single-threaded fuzz test includes the following steps: performing a single-threaded fuzz test on the kernel image for each initial test corpus to obtain the code branch triggered by each initial test corpus; obtaining the branch coverage gain corresponding to each initial test corpus based on the code branch triggered by each initial test corpus, and the single-threaded execution result includes the branch coverage gain.

[0052] The initial test corpus can contain various single-threaded test cases generated according to the Syzlang specification, or initial input data designed for different functional modules of the target kernel. In actual testing, the content and size of the initial test corpus can be flexibly adjusted according to the functional characteristics of the target kernel and testing requirements to ensure comprehensive testing. When conducting single-threaded fuzz testing, a portion of test cases can be randomly or systematically selected from the initial test corpus as the initial test corpus. Then, each initial test corpus is executed independently on the instrumented target kernel image using single-threaded fuzz testing.

[0053] During the execution of each test corpus, the execution trajectory can be captured by monitoring code embedded in the kernel image, accurately determining the specific code branch triggered in the target kernel for each initial test corpus. Based on the triggered code branch information, the kernel code branch coverage before and after executing the test corpus is compared, and the branch coverage gain for each initial test corpus is calculated. This branch coverage gain directly indicates the degree to which each initial test corpus improves the target kernel code branch coverage; a higher gain value indicates a stronger ability of the test corpus to explore new code paths.

[0054] In the specific implementation, the single-threaded execution result not only includes the code branch information triggered by each initial test corpus and the branch coverage gain corresponding to each test corpus, but also the complete execution log of each test corpus, kernel running status and other related information.

[0055] This approach first acquires and selects initial test corpora, then performs single-threaded fuzz testing on each initial test corpus on the target kernel image to capture triggered code branches. The branch coverage gain for each test corpus is then calculated, and the single-threaded execution results are generated. This achieves a quantitative evaluation of the kernel code path exploration capability of each test corpus, accurately selecting test corpora that effectively improve kernel branch coverage. This enhances the targeting and effectiveness of single-threaded fuzz testing, strengthening the quality orientation of subsequent basic corpus construction.

[0056] In the specific implementation, the basic corpus is obtained based on the single-threaded execution result, including: determining the target test corpus based on the branch coverage gain; generating new test corpus based on the target test corpus; updating the initial test corpus based on the new test corpus; repeatedly executing the single-threaded fuzz test on the kernel image based on the initial test corpus to obtain the single-threaded execution result of each single-threaded fuzz test, until the branch coverage gain included in the single-threaded execution result reaches a preset value; the basic corpus is obtained based on the single-threaded execution result, including: obtaining the basic corpus based on the target test corpus at the time of the last execution of the single-threaded fuzz test.

[0057] When determining the target test corpus, branch coverage gain can be used as the core criterion. Initial test corpora with gain values ​​that meet the set standards and can effectively expand the coverage of the target kernel code can be selected as the target test corpus. Alternatively, the execution stability of the test corpus and its coverage of the core kernel modules can be considered for a comprehensive judgment. Furthermore, the target test corpus can be categorized and organized, establishing corresponding subsets based on the covered kernel modules and the types of code branches triggered.

[0058] When generating new test corpora, mutation processing can be performed on the selected target test corpora. This can be achieved through parameter adjustment, instruction insertion, deletion, and rearrangement to generate new test corpora with new execution characteristics. Alternatively, entirely new test corpora can be designed and added to the new test corpora according to the Syzlang specification and the execution patterns of the target test corpora. Throughout the generation process, the goal should always be to improve branch coverage, ensuring that the new test corpora have the potential to explore code paths not covered by the target kernel. After obtaining the new test corpora, they can be integrated into the existing initial test corpora to update the initial test corpora. During the update, corpora with extremely low branch coverage gains and no practical testing value can be removed.

[0059] After updating the initial test corpus, the entire single-threaded fuzzing process can be repeatedly executed on the target kernel image based on the updated corpus, continuously collecting single-threaded execution results and evaluating branch coverage gain. The preset values ​​can be flexibly set according to the testing requirements of the target kernel and the coverage requirements of the core code modules. These can be specific branch coverage values ​​or convergence thresholds for branch coverage gain. When the branch coverage gain included in the single-threaded execution results reaches this preset value, the repeated execution of the single-threaded fuzzing can be stopped.

[0060] When obtaining the basic corpus based on the results of a single-threaded execution, all target test data filtered during the last execution of the single-threaded fuzzy test can be directly extracted and used as the core components of the basic corpus. During the acquisition process, all relevant information about the target test data can be fully retained, including the triggered code branches, the corresponding branch coverage gain, execution configuration, and other contextual information.

[0061] As can be seen, this scheme selects target test corpora based on branch coverage gain, generates new test corpora based on the target test corpora and updates the initial test corpora, and then repeatedly executes single-threaded fuzzing until the branch coverage gain reaches a preset value. Finally, a basic corpus is constructed based on the target test corpora from the last test. This achieves iterative optimization of single-threaded test corpora and continuous improvement of kernel code branch coverage, thereby improving the branch coverage quality and testing value of the basic corpus, enhancing the effectiveness of initial exploration in subsequent concurrent fuzzing, and reducing the proportion of invalid executions.

[0062] In one possible embodiment, concurrent fuzzing is performed on the kernel image based on a base corpus to obtain concurrent execution results, including: initializing a candidate program pool based on the base corpus; selecting a main program from the candidate program pool based on historical test data, which includes test data generated based on the coverage of newly added branches and the coverage of newly added race-proximity access pairs for each candidate program pair; selecting a partner program from the candidate program pool based on the main program to obtain candidate program pairs; allocating a first thread to the main program in the candidate program pair and a second thread to the partner program in the candidate program pair; and concurrently executing the first thread and the second thread to obtain the common branch coverage, race-proximity access pairs, the coverage of race-proximity access pairs, and a set of concurrent candidate pairs, which includes the execution records of each concurrent execution of the candidate program pairs.

[0063] During the initialization of the candidate program pool, all single-threaded test corpora with high branch coverage from the basic corpus can be directly included as candidate programs. After the candidate program pool is initialized and the main program and partner program are selected based on historical test data to form candidate program pairs, the key resource parameters of the candidate program pairs can be standardized or mapped to ensure that the two programs operate on the same shared object. Then, a first thread can be assigned to the main program in the candidate program pair and a second thread can be assigned to the partner program. A dedicated concurrent execution module drives the two threads to perform barrier synchronization concurrent execution on the target kernel image.

[0064] During execution, multi-dimensional core data can be collected simultaneously to form the final concurrent execution results. The common branch coverage reflects the overall coverage of the target kernel code branch by the candidate program during collaborative concurrent execution, a joint coverage effect that cannot be achieved with single-threaded execution. The coverage of race-proximity access pairs characterizes the amount of information about new race-proximity access pairs brought about by concurrent execution, accurately reflecting the degree of concurrent interaction generated by the candidate program during concurrent execution. The concurrent candidate pair set can completely record the full execution record of the candidate program for each concurrent execution, including execution sequence, resource access status, triggering details of race-proximity access pairs, thread interaction status, and other information, providing a complete record of the process and results of each concurrent execution.

[0065] In practice, the filtered coverage of new branches and coverage of new competitive neighbor access pairs can be used as historical test data and sent back to the main program selection, partner selection and program pair evolution modules to update the subsequent selection probability, pairing strategy and evolution direction.

[0066] As can be seen, by initializing the candidate program pool with a basic corpus of high branch coverage, and combining it with historical test data to select suitable main programs and partner programs to form candidate program pairs, independent threads are allocated to program pairs for concurrent execution. Simultaneously, multi-dimensional data such as common branch coverage, race condition proximity access pairs and their coverage, and concurrent execution records are collected, allowing concurrent testing to start from high-quality candidate program combinations. This avoids blind program pairing, accurately captures core interactions and coverage information in concurrent execution, thereby improving the exploration focus and execution controllability of concurrent fuzzing, and enhancing the ability to discover concurrent candidate signals and the comprehensiveness of data collection.

[0067] In the specific implementation, the concurrent corpus is determined based on the concurrent execution results, including: performing the following operations for each candidate program pair: executing the main program and partner program of the current candidate program pair independently multiple times in a single-threaded environment to obtain the first branch coverage of the main program, the second branch coverage of the partner program, and a single-threaded candidate pair set, which includes the execution records of each independent execution of the current candidate program pair; determining the concurrent branch coverage increment based on the common branch coverage of the current candidate program pair and the first and second branch coverages; determining whether the current candidate program pair includes the newly added branch coverage and the newly added race-proximity access pair coverage based on the first branch coverage, the second branch coverage, the single-threaded candidate pair set, the concurrent branch coverage increment, the coverage of race-proximity access pairs, and the concurrent candidate pair set; if so, determining the current candidate program pair as the target candidate program pair; and determining the concurrent corpus based on the target candidate program pair.

[0068] When processing each candidate program pair, the main program and its partner program can be executed independently multiple times in a pure single-threaded environment. During independent execution, the kernel runtime environment and monitoring configuration remain consistent with those used during concurrent execution. This yields the first branch coverage of the main program when executed alone and the second branch coverage of the partner program when executed alone. Simultaneously, the full execution records of the main program and partner program's individual single-threaded executions can be collected and integrated into a single-threaded candidate pair set. This set can include information such as resource access details, code branch triggering details, and memory access operation records for each independent execution, providing a complete comparison with the concurrent candidate pair set.

[0069] After obtaining the relevant data for single-threaded execution, the incremental concurrent branch coverage can be determined by calculating the difference between the common branch coverage of the current candidate program and the coverage of the first branch of the main program and the second branch of the partner program. During the calculation, code branches already covered by single-threaded execution can be precisely eliminated, retaining only the new branch coverage increment brought about by concurrent execution, thereby quantitatively reflecting the added value of the program's control flow exploration for concurrent execution.

[0070] Subsequently, a comprehensive comparative analysis can be performed on the coverage of the first branch, the coverage of the second branch, the single-threaded candidate pair set, the concurrent branch coverage increment, the coverage of race-proximity access pairs, and the concurrent candidate pair set to determine whether the candidate program pair includes new branch coverage and new race-proximity access pair coverage. Specifically, this can be achieved by verifying whether the concurrent branch coverage increment is a valid positive value and filtering out race-proximity access pairs that do not appear in the single-threaded candidate pair set but only exist in the concurrent candidate pair set, thereby determining whether there is a new coverage truly generated by cross-program concurrent interaction. If the comparison confirms the existence of such a new coverage, the current candidate program pair can be determined as the target candidate program pair. After completing the evaluation of all candidate program pairs one by one, all the filtered target candidate program pairs can be integrated. At the same time, the barrier concurrent execution configuration, the confirmed set of new race-proximity access pairs, and related context information corresponding to each target candidate program pair can be fully associated to determine the final concurrent corpus.

[0071] As can be seen, by conducting single-threaded comparative executions on candidate program pairs to obtain single-threaded coverage and execution data, and then calculating the incremental concurrent branch coverage and comparing it with the single-threaded and concurrent full data, target candidate program pairs with newly added branch coverage and newly added race-state proximity access coverage are selected, and a concurrent corpus is constructed. This method accurately removes noise signals that can be interpreted by a single thread from the concurrent execution results, retaining only the valid signals generated by cross-program concurrent interactions. This improves the accuracy and effectiveness of candidate content in the concurrent corpus, enhancing the targeting and efficiency of subsequent data competition verification based on the concurrent corpus.

[0072] In one possible embodiment, selecting the main program from the candidate program pool based on historical test data includes: initializing a set of distribution parameters for each initialization candidate program in the initialization candidate program pool, wherein the distribution parameters are updated according to whether the main program generates new interactive data during subsequent concurrent execution; sampling each initialization candidate program based on its corresponding distribution parameters to obtain a sampled value; and determining the initialization candidate program with the largest sampled value among the multiple initialization candidate programs as the main program.

[0073] In this context, a set of Beta distribution parameters is maintained for each candidate program. Thompson sampling was used to sample from... Mid-sampling The program with the largest sample value is then prioritized as the main program. After obtaining the sample values ​​of all initialization candidate programs, all sample values ​​can be compared and sorted to directly determine the initialization candidate program with the largest sample value as the main program for this concurrent fuzzy test. The selection process can directly use the sample value as the sole criterion, without introducing additional screening conditions, ensuring the simplicity and objectivity of the main program selection. Alternatively, for candidate programs with the same sample value, further judgment can be made based on their concurrent interaction performance in historical test data to determine the final main program.

[0074] It is evident that the main program selected in this way has a high level of concurrent exploration potential reflected by its distribution parameters, which makes it easier for subsequent partner programs matched based on the main program to form candidate program pairs with effective concurrent interaction capabilities.

[0075] In practice, new interaction data can include effective data resulting from cross-program concurrent interaction, such as new branch coverage and new race condition proximity access pair coverage, generated after the main program and its partner program form a candidate program pair and execute concurrently. During the judgment process, the results of the current concurrent execution involving the main program can be comprehensively compared with the main program's historical test data and single-threaded execution data to accurately filter out entirely new data content generated solely by this concurrent interaction, thereby clarifying whether the main program has generated valid new interaction data. Alternatively, a valid threshold for new interaction data can be set, recognizing only new data reaching the threshold as valid output to ensure the objectivity of the judgment results.

[0076] When updating the distribution parameters of the main program based on whether new interactive data has been generated, these distribution parameters are Beta distribution parameters used by the main program for selection. If it is determined that the main program has generated valid new interactive data during this concurrent execution, its corresponding distribution parameters can be positively updated, and the parameter values ​​can be appropriately adjusted to increase the probability of the main program obtaining high sample values ​​in subsequent samplings. If it is determined that the main program has not generated valid new interactive data, its corresponding distribution parameters can be negatively updated, and the parameter values ​​can be fine-tuned to reduce the probability of the main program obtaining high sample values ​​in subsequent samplings.

[0077] When updating distribution parameters, a gradient update rule can be set according to the quantified value of the newly added interactive data. The higher the value of the newly added interactive data, the greater the positive adjustment of the parameters, so that the degree of parameter update matches the actual concurrent output of the main program.

[0078] It is evident that by determining whether the main program generates new interactive data during subsequent concurrent execution, and updating the distribution parameters of the main program accordingly based on the determination results, the distribution parameters can be aligned with the actual concurrent interactive output of the main program in real time. This improves the accuracy and rationality of selecting the main program based on the distribution parameters, and enhances the effectiveness and guidance of subsequent candidate programs in the formation of concurrent exploration.

[0079] In one possible embodiment, selecting a partner program for the main program from a pool of candidate programs includes: determining the number of concurrent executions and the number of effective outputs for each candidate program in the pool during historical concurrent execution, where effective outputs indicate that the candidate program has new interactive data; calculating the affinity between each main program and other candidate programs in the pool based on the number of concurrent executions and the number of effective outputs; obtaining multiple reference partner programs for each main program from the pool; determining the combination score for each reference program pair based on the affinity, where each reference program pair includes one main program and one reference partner program; and determining the partner program for each main program based on the combination score.

[0080] The system maintains an affinity matrix for system call pairs, recording the number of concurrent executions of a particular system call pair in historical concurrent executions. and the number of effective outputs And calculate the affinity based on this. Then aggregate them into program-level affinity. The partner selector comprehensively considers the partner program's concurrency potential score, length penalty, program-level affinity, and program's cooldown penalty to form a combined score. Based on this, candidate partners are sorted or sampled, thereby making the constructed program more likely to include combinations of system calls that are historically more likely to form shared resource interactions, thus improving the effectiveness of concurrent exploration.

[0081] For example Figure 3 As shown, after selecting the primary program from the candidate pool via the primary selector and the partner program from the candidate pool via the partner selector, explicit resource alignment can be performed first based on object joins when generating candidate program pairs. Since even if two programs contain the same system calls, it is difficult to achieve true resource sharing if their resource parameters (such as paths, file descriptors, or device handles) point to different kernel objects, it is crucial to unify or map the key resource parameters of the two programs during the program pair construction phase. This ensures that the two programs operate on the same type of object or the same object instance as much as possible, thereby increasing the probability of accessing shared resources and expanding the concurrent interaction window.

[0082] After constructing the program pairs, the system can perform mutation and evolution on the candidate program pairs to generate new program pair test cases. Mutation and evolution include operations such as parameter mutation, insertion, deletion, and rearrangement, and introduces an affinity-oriented strategy during mutation decisions. This includes prioritizing expansion or perturbation around system call combinations with high affinity, thereby continuously enhancing the interaction strength of shared resources while maintaining semantic executability. The new program pairs generated by mutation enter the subsequent concurrent execution phase and generate runtime feedback. The system then incrementally filters the concurrent execution results and updates the model. This includes comparing the set of concurrent candidate pairs obtained from concurrent execution with the set of single-threaded candidate pairs obtained from two separate executions, eliminating access pairs that could be generated by separate executions, and retaining only the interaction evidence newly added under concurrent conditions as race-proximity access pairs; these race-proximity access pairs are used as unified feedback signals to update the statistics table, affinity matrix, RPP prediction library, and single corpus, etc. This forms a closed loop of "selection—pairing—alignment—mutation—feedback—update," ensuring that the generation direction continuously focuses on program pairs with stronger concurrency relevance.

[0083] In one possible embodiment, obtaining the data competition test results of the target kernel based on the race-proximity access pair includes: obtaining race-proximity access pairs from a concurrent corpus; performing multiple rounds of repeated concurrent tests on the race-proximity access pairs to obtain a multi-round test result set; obtaining a stable-triggered reference race-proximity access pair based on the multi-round test result set to obtain a reference race-proximity access pair set; performing controlled verification operation on the reference race-proximity access pair set to obtain the competition test results; and persistently storing the reference race-proximity access pair when the competition test results indicate that the reference race-proximity access pair is the target race-proximity access pair.

[0084] The process begins by extracting all race-proximity access pairs (RPAs) after single-threaded noise removal from the existing concurrent corpus. Simultaneously, contextual information such as candidate program pairs and barrier concurrent execution configurations for each RPA can be extracted to form a complete list of pairs to be verified. Multiple rounds of repeated concurrent testing are then performed on all RPAs to be verified. During testing, the corresponding program pairs and execution configurations can be reused, and multiple concurrent runs are conducted on the target kernel image according to the same execution rules. Simultaneously, monitoring code within the kernel comprehensively collects data on the triggering status, execution sequence, and memory access details of RPAs in each round of testing. The test data from all rounds is integrated into a multi-round test result set. Data collection ensures a consistent running environment for each round of testing, reducing the interference of environmental fluctuations on the test results.

[0085] Among them, the reference race-proximity access pairs that are stably triggered are not triggered by accidental factors such as scheduling jitter or changes in cache state, but rather are race-proximity access pairs that reach a preset trigger frequency or percentage threshold and exhibit stable occurrence characteristics in multiple rounds of repeated concurrent tests. During the determination process, the results sets from multiple rounds of tests can be aggregated and statistically analyzed to calculate the actual number of triggers and trigger rate for each race-proximity access pair. Then, race-proximity access pairs whose trigger indicators meet the preset standards are defined as stably triggered reference race-proximity access pairs. The determination thresholds such as trigger frequency and trigger rate can also be flexibly adjusted according to testing needs, balancing testing accuracy and exploration efficiency.

[0086] For the identified target race condition proximity access pairs, they can be written completely to the result persistence medium. During the writing process, the corresponding competition test results, controlled verification execution configuration, concurrent access evidence, triggering conditions, and other related information can be stored simultaneously. Alternatively, the content in the result persistence medium can be structured and categorized according to dimensions such as the triggering location of data competition and associated kernel modules. This facilitates rapid retrieval and review during subsequent kernel issue troubleshooting and repair, while ensuring the traceability and verifiability of the stored content.

[0087] In the specific implementation, if it is not the target race state neighbor access pair, the failure conclusion and context information of the reference race state neighbor access pair are obtained based on the race test results; the failure conclusion and context information are written into the result persistence medium.

[0088] When a reference race condition proximity pair is not identified as a target race condition proximity pair, the system can directly analyze and obtain its failure conclusions and related contextual information based on the corresponding race condition proximity pair's competition test results. The failure conclusions clearly define the core reasons why the reference race condition proximity pair did not become the target, such as the failure to trigger actual data competition, the pair being a stable race condition candidate without real data competition risk, or the inability to form effective memory access interleaving under latency control strategies. The competition test results can be broken down and analyzed according to preset judgment rules. The contextual information can include the basic identifier of the reference race condition proximity pair, the corresponding candidate program pair and barrier concurrent execution configuration, trigger statistics from multiple rounds of repeated concurrent tests, specific parameters and execution logs of controlled verification runs, and concurrent access evidence collected by kernel-side detectors—a complete set of related information. During the acquisition process, this information can be precisely bound to the reference race condition proximity pair to ensure that the contextual information can fully reconstruct the entire process details of the candidate from testing to verification.

[0089] After obtaining the failure conclusions and context information, both types of information can be written to the persistent result medium. The writing process can employ a structured storage method consistent with the target race condition proximity access pairs. This allows for direct retrieval of this stored information when optimizing concurrent fuzzing processes, adjusting controlled verification decision rules, or delay control strategies. This enables analysis of the common characteristics of invalid candidates, providing real and effective data support for iterative optimization of the test plan.

[0090] In practice, it is also possible to obtain statistical information from multiple rounds of repeated concurrent tests, which indicates the test status of each round of concurrent tests; and write the statistical information to the result persistence medium.

[0091] The statistics include the execution time of each round of concurrent tests, kernel running status, specific triggering details of race condition proximity pairs, timing details of thread interactions, specific records of memory accesses, and core data such as the total number of triggers, trigger rate, and trigger stability of race condition proximity pairs across all test rounds. During the acquisition process, the monitoring code and test execution log recording module in the target kernel image can be used to collect and initially organize the process data for each round of tests in real time. Information from each round of tests can also be extracted in a structured manner according to a unified dimension. Simultaneously, the collected raw data can be simply cleaned to remove invalid test records, ensuring that the final statistics accurately reflect the actual execution status of multiple rounds of repeated concurrent tests. By acquiring the statistical information indicating the test status of each round of repeated concurrent tests and writing it to the persistent results medium, the full process data of the race condition proximity pair test is completely preserved, thereby improving the traceability and comprehensiveness of the data competition test results and enhancing the effectiveness of subsequent optimization of concurrent test strategies and mining of race condition triggering patterns based on test data.

[0092] In one possible embodiment, multiple rounds of repeated concurrent testing are performed on race-proximity access pairs to obtain a multi-round test result set, including: generating a test environment for race-proximity access pairs through state restoration and virtual machine snapshots; performing multiple rounds of repeated concurrent testing on the items to be verified in the test environment to obtain a multi-round test result set; obtaining a stably triggered reference race-proximity access pair based on the multi-round test result set, including: obtaining the number of times the same race-proximity access pair appears in the multi-round test result set; and obtaining a stably triggered reference race-proximity access pair based on the number of occurrences.

[0093] Among them, for example Figure 4As shown, when performing multiple rounds of repeated concurrent tests on race condition proximity pairs, a dedicated test environment for each race condition proximity pair can be generated using state restoration techniques and virtual machine (VM) snapshots. State restoration techniques can accurately restore the target kernel's critical runtime state, initial memory state, and program execution context related to the race condition proximity pair. VM snapshots can solidify the complete system environment at test startup, including kernel configuration and thread initial states. The combination of these two methods ensures that each round of repeated concurrent tests starts and executes in a completely consistent environment, avoiding the impact of environmental fluctuations, state remnants, and other factors on the objectivity of the test results.

[0094] After generating the test environment, multiple rounds of repetitive concurrent tests can be performed on the items to be verified, including race-proximity access pairs and their associated contexts, within this standardized environment. Each round of testing follows the same execution rules and scheduling strategy. Simultaneously, relying on the monitoring code in the target kernel image, comprehensive data such as the triggering status of race-proximity access pairs, memory access details, and thread interaction timings are collected for each round. By integrating the test data from all rounds in a unified format, a multi-round test result set can be obtained.

[0095] When obtaining stable-triggered reference race condition proximity access pairs based on multi-round test result sets, the result sets can be aggregated and statistically analyzed first. The actual occurrence count of the same race condition proximity access pair across all test rounds can be extracted. During the statistical process, invalid trigger records caused by test anomalies, environmental interruptions, etc., can be excluded to ensure that the statistical count accurately reflects the actual triggering status of the race condition proximity access pair. Then, stable-triggered reference race condition proximity access pairs are obtained based on the statistically obtained occurrence counts. A reasonable trigger count threshold can be preset, and race condition proximity access pairs whose occurrence count reaches this threshold are judged as stable-triggered reference race condition proximity access pairs. Alternatively, the trigger rate can be calculated based on the total number of test rounds, and race condition proximity access pairs whose trigger rate reaches a preset standard can be included in the reference set. The threshold or trigger rate standard can be flexibly adjusted according to test requirements, balancing test accuracy and efficiency. Reference race condition proximity access pairs selected in this way can effectively exclude single triggers caused by accidental factors such as scheduling jitter and cache changes, ensuring their stable triggering potential. This lays the foundation for accurately amplifying the race condition window and capturing real data competition clues in the subsequent controlled verification phase.

[0096] In one possible embodiment, a controlled verification run is performed on a set of reference race-state neighbor access pairs to obtain race test results, including: obtaining historical race test results for each reference race-state neighbor access pair in the set; determining the verification skip probability for each reference race-state neighbor access pair based on the historical race test results; obtaining the category of each reference race-state neighbor access pair; determining a verification scheduling strategy based on the category; determining the current reference race-state neighbor access pair based on the verification skip probability and verification scheduling strategy for each reference race-state neighbor access pair in the set; performing the following operations for each reference race-state neighbor access pair in the set: performing state restoration for the current verification round to obtain a target state; determining a delay control strategy for the current reference race-state neighbor access pair based on the timing characteristics of the current reference race-state neighbor access pair, where delay control includes startup delay and / or access delay; and in the target state, executing the program pair and barrier concurrency configuration corresponding to the current reference race-state neighbor access pair according to the delay control strategy to obtain race test results.

[0097] This process involves obtaining a set of race-proximity access pairs from a concurrent corpus, and then performing verification operations on each reference race-proximity access pair in the reference race-proximity access pair set. Each round of verification begins with state restoration, performing a dedicated state restoration operation for the current verification round. Through lightweight state restoration techniques, the system accurately restores the target kernel's critical runtime state, initial memory state, program execution context, and initial thread configuration related to the current reference race-proximity access pair. This ensures that each verification starts in a consistent initial state, avoiding the influence of state residue or environmental interference from the previous round on the verification results. The restored state becomes the target state adapted to the verification of the current reference race-proximity access pair, providing a stable foundation for subsequent latency control and concurrent execution.

[0098] After obtaining the target state, the timing characteristics of the current reference race condition neighboring access pair are considered to determine the corresponding latency control strategy. Latency control includes startup latency and / or access latency. Startup latency can be used to adjust the startup order of the two threads in the corresponding program pair of the reference race condition neighboring access pair. Access latency can precisely control the timing of thread access to shared memory resources. When determining the strategy, the trigger timing and memory access interval characteristics of the current reference race condition neighboring access pair in multiple rounds of repeated concurrent tests can be analyzed to determine the timing window most likely to trigger data races, and then reasonable latency parameters can be set. For example, appropriate access latency can be configured for threads with similar access timings to artificially increase the probability of concurrent interleaving between threads. Alternatively, depending on the type of reference race condition neighboring access pair, flexible options can be selected to configure only startup latency, only access latency, or both latency simultaneously, ensuring that the latency control strategy accurately adapts to the triggering characteristics of the current reference race condition neighboring access pair.

[0099] After determining the delay control strategy, under the restored target state, the candidate program pairs and barrier concurrency configurations corresponding to the current reference race condition proximity access pair are executed strictly according to this strategy. During execution, the kernel runtime environment remains consistent with multiple rounds of repeated concurrent testing. Simultaneously, monitoring code pre-embedded in the target kernel image and kernel-side detectors are used to capture in real time the thread execution trajectory, memory access details, triggering status of race condition proximity access pairs, and evidence of data races. Integrating and analyzing this collected verification data with execution logs yields the competition test results corresponding to the current reference race condition proximity access pair. After each reference race condition proximity access pair has been verified using this process, all independent competition test results are integrated to form the competition test results for the entire set of reference race condition proximity access pairs, providing direct evidence for subsequent determination of the target race condition proximity access pair.

[0100] As can be seen, by performing state restoration for each verification round of the reference race state neighbor access pair to ensure the consistency of the verification environment, and combining its timing characteristics to determine the delay control strategy including startup delay and / or access delay, and then executing the corresponding program pair and barrier concurrent configuration according to the strategy under the target state, the concurrent race state window is artificially amplified and data competition-related evidence is accurately captured, thereby improving the accuracy and effectiveness of the controlled verification of the reference race state neighbor access pair and enhancing the ability of the competition test results to identify real data competition.

[0101] In practice, the historical competition test results for each reference race condition neighbor access pair in the reference race condition neighbor access pair set can be obtained first. These historical competition test results can include the execution records of every controlled verification of the reference race condition neighbor access pair, the competition test conclusions, and the specific reasons for verification failures or successes, along with all associated data. During the acquisition process, the historical verification information corresponding to each reference race condition neighbor access pair can be precisely retrieved from the persistent results medium. Alternatively, the historical data can be structured and categorized according to dimensions such as verification time and verification results to facilitate subsequent probability calculations.

[0102] Subsequently, based on the obtained historical competition test results, the verification skip probability of each reference competition state neighbor access pair is determined one by one. The calculation can incorporate quantitative analysis of factors such as the success rate of past verifications, the number of invalid repeated verifications, and whether the same failure conclusion has occurred multiple times. For example, a higher verification skip probability can be set for reference competition state neighbor access pairs that have not triggered data competition in multiple past verifications and have consistent failure conclusions. A lower verification skip probability can be set for reference competition state neighbor access pairs that have shown suspected data competition clues in the first verification or in previous verifications. The weighting of the probability calculation can also be flexibly adjusted according to testing needs, so that the verification skip probability can truly reflect the value and necessity of re-verifying the reference competition state neighbor access pair.

[0103] While determining the verification skip probability, the category of each reference race condition neighbor access pair can be obtained. Classification can be based on dimensions such as the kernel module corresponding to the reference race condition neighbor access pair, the triggered memory access type, and the characteristics of the associated candidate program pairs. For example, it can be divided into different categories such as kernel driver-related race condition neighbor access pairs and memory management-related race condition neighbor access pairs. When obtaining the category, the context identifier information of the reference race condition neighbor access pair can be directly extracted. Alternatively, configuration and execution characteristics can be combined with its associated program to classify the pairs, ensuring that each reference race condition neighbor access pair can be accurately classified into its corresponding category.

[0104] Next, based on the category of each reference race condition proximity access pair, a corresponding verification scheduling strategy is determined. Different categories of reference race condition proximity access pairs can be adapted to different scheduling priorities and verification resource allocation schemes. For example, for reference race condition proximity access pairs related to core kernel modules, a higher verification priority can be set, allocating more verification resources and time preferentially. For non-core modules and categories with low trigger frequency, a relatively lower priority can be set, and verification resources can be allocated reasonably. Alternatively, based on the common characteristics of the categories, uniform preset values ​​for verification parameters can be set for the same category, reducing the configuration time of subsequent latency control strategies.

[0105] Finally, by combining the verification skip probability of each reference race condition neighbor access pair with the corresponding verification scheduling strategy, the reference race condition neighbor access pairs that currently require controlled verification are comprehensively determined. During this determination, the verification priority of each reference race condition neighbor access pair can be first determined based on the verification scheduling strategy, and then filtered based on the verification skip probability. Reference race condition neighbor access pairs with high priority and low skip probability are prioritized for verification. Reference race condition neighbor access pairs with low priority and high skip probability can be temporarily skipped, or the filtering rules can be flexibly adjusted according to the overall verification progress. This ensures that high-value reference race condition neighbor access pairs are focused on to improve verification efficiency, while also preventing the omission of potential data competition risks, thus laying the foundation for the efficient implementation of subsequent controlled verification.

[0106] As can be seen, before performing controlled verification on the set of reference race-state neighbor access pairs, a series of additional filtering and scheduling operations are performed to determine the reference race-state neighbor access pairs that need to be verified under controlled conditions. This enables the reasonable allocation of verification resources, avoids invalid verification operations, improves the overall efficiency of controlled verification, and ensures the relevance and comprehensiveness of the verification.

[0107] Please see Figure 5The overall process of this application will be explained below. First, in the compilation stage, this solution takes the unmodified kernel and its submodules as the test objects. During the compilation process, non-local variable access instrumentation is performed on the submodules so that they can output concurrent interaction-related event information at runtime. The compilation artifacts are then linked with the custom module to generate a bootable target kernel image, thereby providing a unified runtime signal acquisition interface for subsequent stages and supporting latency control and data contention monitoring.

[0108] Secondly, in the single-threaded fuzz testing phase, the test input is run and the branch coverage is collected through a single-threaded execution module. The branch coverage gain is used as feedback to drive input generation and mutation, gradually forming a basic corpus with high branch coverage. This enables exploration to be carried out on high-quality input in the concurrent phase, reducing invalid runs and improving the initial hit rate.

[0109] Furthermore, in the concurrent fuzzing phase, a processing chain is established, encompassing program pair generation, barrier synchronous concurrent execution, dual-signal coverage acquisition, single-threaded noise filtering, and feedback-driven evolution. Program pairs are constructed through main program selection and partner selection, and object linking can be optionally executed to increase the probability of shared resources. Subsequently, barrier synchronization is adopted for concurrent execution, ensuring that the two execution contexts are aligned and run in parallel as much as possible during critical stages, thereby amplifying the race condition window and improving the controllability of concurrent execution. Simultaneously, two types of coverage signals are acquired: branch coverage and race condition proximity access pair coverage. Branch coverage characterizes the progress of control flow exploration, while race condition proximity access pair coverage characterizes the amount of new candidate pair information brought about by concurrent interactions, thus avoiding ignoring the value of concurrent interactions by relying solely on branch coverage.

[0110] Next, to reduce the degradation in candidate quality caused by single-threaded interpretable noise mixed in the concurrent execution results, this solution uses a post-processing filtering module to run each program pair in a single thread to obtain single-threaded achievable coverage and candidate pair set, and filters out the parts in concurrent execution that can be interpreted by any single thread, retaining only the new coverage and new race-proximity access pairs that are more consistent with the semantics of cross-program concurrent interaction. Subsequently, the filtered program pairs and their associated signals are written into the concurrent corpus, and the new branch coverage, new race-proximity access pair coverage, and filtering results are fed back to the main program selection, partner selection, and evolution modules, forming an adaptive closed loop of generation, execution, collection, filtering, and feedback, so that computing resources are continuously focused on test cases with stronger concurrency correlation and more concentrated competition windows.

[0111] Finally, in the verification phase, multiple rounds of collection and stable screening are performed on candidates in the concurrent corpus, and controlled verification transforms candidate signals into reproducible results. Successful and unsuccessful candidates are written to persistent files, along with variable names or candidate category-related statistical information, to ensure traceability and reusability of results and provide a basis for subsequent verification scheduling and resource allocation. Through this process, this solution can improve the efficiency of concurrent candidate output, reduce single-threaded noise interference, and enhance the stability and confidence of results at a controllable cost.

[0112] Please see Figure 6 A fuzzing device 600 for testing data contention in an operating system kernel includes: a generation unit for generating a kernel image of the target kernel, using the operating system to be tested as the target kernel; a first testing unit for performing single-threaded fuzzing on the kernel image to obtain single-threaded execution results; a first acquisition unit for acquiring a basic corpus based on the single-threaded execution results; a second testing unit for performing concurrent fuzzing on the kernel image based on the basic corpus to obtain concurrent execution results; a determination unit for determining a concurrent corpus based on the concurrent execution results, wherein the concurrent corpus includes race condition proximity access pairs; wherein each race condition proximity access pair includes a first memory access operation and a second memory access operation, the first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap, and the access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation; and a second acquisition unit for acquiring the data contention test results of the target kernel based on the race condition proximity access pairs.

[0113] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application. For example... Figure 7As shown, the electronic device may include a processor 710, a communications interface 720, a memory 730, and a communication bus 740. The processor 710, communications interface 720, and memory 730 communicate with each other via the communication bus 740. The processor 710 can invoke logical instructions from the memory 730 to execute a fuzzing method for data contention within the operating system kernel. The method includes: generating a kernel image of the target kernel using the operating system to be tested as the target kernel; performing a single-threaded fuzz test on the kernel image to obtain the single-threaded execution result; obtaining a basic corpus based on the single-threaded execution result; performing a concurrent fuzz test on the kernel image based on the basic corpus to obtain the concurrent execution result; determining a concurrent corpus based on the concurrent execution result, wherein the concurrent corpus includes race-proximity access pairs; wherein the race-proximity access pairs include a first memory access operation and a second memory access operation, the first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap, and the access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation; and obtaining the data race test result of the target kernel based on the race-proximity access pairs.

[0114] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the fuzzing method for data contention in the operating system kernel provided by the methods described above. The method includes: generating a kernel image of the target kernel, using the operating system to be tested as the target kernel; performing a single-threaded fuzzing test on the kernel image to obtain a single-threaded execution result; obtaining a basic corpus based on the single-threaded execution result; performing a concurrent fuzzing test on the kernel image based on the basic corpus to obtain a concurrent execution result; determining a concurrent corpus based on the concurrent execution result, the concurrent corpus including race-proximity access pairs, each indicating two memory access behaviors that are close to forming a data contention in a single run; and obtaining the data contention test result of the target kernel based on the race-proximity access pairs.

[0116] Furthermore, this application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the aforementioned fuzzing methods for data contention in an operating system kernel. The method includes: generating a kernel image of the target kernel, using the operating system to be tested as the target kernel; performing a single-threaded fuzzing test on the kernel image to obtain single-threaded execution results; obtaining a basic corpus based on the single-threaded execution results; performing a concurrent fuzzing test on the kernel image based on the basic corpus to obtain concurrent execution results; determining a concurrent corpus based on the concurrent execution results, the concurrent corpus including race condition proximity pairs, each indicating two memory access behaviors that nearly result in data contention during a single run; and obtaining the data contention test results of the target kernel based on the race condition proximity pairs.

[0117] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fuzzing method for data contention in operating system kernels, characterized in that, include: Using the operating system to be tested as the target kernel, generate a kernel image of the target kernel; A single-threaded fuzz test was performed on the kernel image to obtain the single-threaded execution results. The basic corpus is obtained based on the single-threaded execution result. Based on the aforementioned basic corpus, a concurrent fuzz test is performed on the kernel image to obtain concurrent execution results; A concurrent corpus is determined based on the concurrent execution results. The concurrent corpus includes race-proximity access pairs. Each race-proximity access pair includes a first memory access operation and a second memory access operation. The first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap. The access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation. The data competition test results of the target kernel are obtained based on the race-proximity access pair.

2. The method according to claim 1, characterized in that, The generation of the kernel image of the target kernel includes: The initial taint source is determined based on the kernel functions of the target kernel; The taint variable propagation path of the initial taint source is determined based on the function control flow graph of the kernel function; Based on the tainted variable propagation path, access instructions involving tainted variables are marked as candidate shared access points; Under the kernel compilation framework to which the target kernel belongs, monitoring code is inserted into the candidate shared access points to obtain reference kernel code; Generate a kernel image of the target kernel based on the reference kernel code.

3. The method according to claim 1, characterized in that, The single-threaded fuzz test performed on the kernel image yields the following single-threaded execution results: Obtain the initial test corpus; The initial test corpus is obtained based on the initial test corpus set. A single-threaded fuzz test is performed on the kernel image based on the initial test corpus to obtain a single-threaded execution result. The single-threaded fuzz test includes the following steps: performing a single-threaded fuzz test on the kernel image for each initial test corpus to obtain the code branch triggered by each initial test corpus; obtaining the branch coverage gain corresponding to each initial test corpus based on the code branch triggered by each initial test corpus; and the single-threaded execution result includes the branch coverage gain. The step of obtaining the basic corpus based on the single-threaded execution result includes: The target test corpus is determined based on the branch coverage gain. Generate new test corpus based on the target test corpus; The initial test corpus is updated based on the newly added test corpus. The single-threaded fuzz test is repeatedly executed on the kernel image based on the initial test corpus to obtain the single-threaded execution result of each single-threaded fuzz test until the branch coverage gain included in the single-threaded execution result reaches a preset value. The basic corpus is obtained based on the target test corpus from the last execution of the single-threaded fuzz test.

4. The method according to claim 1, characterized in that, The step of performing concurrent fuzz testing on the kernel image based on the basic corpus to obtain concurrent execution results includes: Initialize the candidate program pool based on the aforementioned basic corpus; The main program is selected from the candidate program pool based on historical test data, which includes test data generated based on the coverage of newly added branches and newly added race-proximity access pairs for each candidate program. Based on the main program, a partner program is selected from the candidate program pool to obtain a candidate program pair; A first thread is assigned to the main program in the candidate program pair, and a second thread is assigned to the partner program in the candidate program pair. The first thread and the second thread are executed concurrently to obtain the common branch coverage of the candidate program pair, the race-proximity access pair, the coverage of the race-proximity access pair, and the concurrent candidate pair set, which includes the execution record of each concurrent execution of the candidate program pair; The step of determining the concurrent corpus based on the concurrent execution results includes: For each candidate program pair, perform the following operations: Execute the main program and its partner program in the current candidate program pair independently multiple times in a single-threaded environment to obtain the first branch coverage of the main program, the second branch coverage of the partner program, and a single-threaded candidate pair set, where the single-threaded candidate pair set includes the execution records of each independent execution of the current candidate program pair; determine the concurrent branch coverage increment based on the common branch coverage of the current candidate program pair, the first branch coverage, and the second branch coverage; determine whether the current candidate program pair includes new branch coverage and new competitive proximity access pair coverage using the first branch coverage, the second branch coverage, the single-threaded candidate pair set, the concurrent branch coverage increment, the coverage of the race condition proximity access pair, and the concurrent candidate pair set; if so, determine the current candidate program pair as the target candidate program pair; and determine the concurrent corpus based on the target candidate program pair.

5. The method according to claim 4, characterized in that, The step of selecting the main program from the candidate program pool based on historical test data includes: A set of distribution parameters is initialized for each initialization candidate program in the initialization candidate program pool. The distribution parameters are updated according to whether the main program generates new interactive data during subsequent concurrent execution. For each initialization candidate program, a sample value is obtained by sampling based on its corresponding distribution parameter; The initialization candidate program with the largest sample value among multiple initialization candidate programs is determined as the main program.

6. The method according to claim 4, characterized in that, The step of selecting a partner program for the main program from the candidate program pool based on the main program includes: Determine the number of concurrent executions and the number of effective outputs for each candidate program in the candidate program pool during the historical concurrent execution process. Effective outputs indicate that the candidate program has newly added interactive data. The affinity between each main program and other candidate programs in the candidate program pool is calculated based on the number of concurrent executions and the number of effective outputs. Obtain multiple reference partner programs for each main program from the candidate program pool; The combination score of each reference program pair is determined based on the affinity, wherein the reference program pair includes a main program and a reference partner program; The partner program for each main program is determined based on the combined score.

7. The method according to claim 1, characterized in that, The step of obtaining the data contention test results of the target kernel based on the race proximity access pair includes: Obtain race-proximity access pairs from the concurrent corpus; Perform multiple rounds of repeated concurrent tests on the race-proximity access pairs to obtain a set of test results from multiple rounds; Based on the multi-round test result set, obtain the stable triggered reference race state neighbor access pair to obtain the reference race state neighbor access pair set; A controlled verification operation is performed on the reference race-state neighbor access pair set to obtain race test results. When the race test results indicate that the reference race-state neighbor access pair is the target race-state neighbor access pair, the reference race-state neighbor access pair is persistently stored.

8. The method according to claim 7, characterized in that, The process of performing multiple rounds of concurrent testing on the race-proximity access pair yields a set of test results, including: The test environment for the race-state proximity access pairs is generated using state restoration techniques and virtual machine snapshots. Multiple rounds of repeated concurrent testing are performed on the item to be verified in the test environment to obtain a set of test results from multiple rounds. The step of obtaining stable-triggered reference race-state proximity access pairs based on the multi-round test result set includes: Obtain the number of times the same competitive proximity pair appears in the multi-round test result set; Based on the number of times, obtain a stable triggering reference race condition neighbor access pair.

9. The method according to claim 7, characterized in that, The controlled verification run on the reference race-state proximity access pair set to obtain race test results includes: Obtain the historical competition test results for each reference race-state neighbor access pair in the reference race-state neighbor access pair set; The verification skip probability of each reference race state neighbor access pair is determined based on the historical race test results. Obtain the category of each reference race condition neighbor access pair; Determine the verification scheduling strategy based on the category; The current reference race condition neighbor access pair is determined based on the verification skip probability of each reference race condition neighbor access pair and the verification scheduling policy; For each reference race condition neighbor access pair in the set of reference race condition neighbor access pairs, the following operations are performed: State restoration is performed for the current verification round to obtain the target state; based on the timing characteristics of the current reference race condition neighbor access pair, a delay control strategy for the current reference race condition neighbor access pair is determined, the delay control including startup delay and / or access delay; in the target state, the program pair and barrier concurrency configuration corresponding to the current reference race condition neighbor access pair are executed according to the delay control strategy to obtain the race test results.

10. A fuzz testing device for data contention in an operating system kernel, characterized in that, include: The generation unit is used to generate a kernel image of the target kernel, using the operating system to be tested as the target kernel. The first test unit is used to perform a single-threaded fuzz test on the kernel image and obtain the single-threaded execution result. The first acquisition unit is used to acquire the basic corpus based on the single-thread execution result. The second testing unit is used to perform concurrent fuzz testing on the kernel image based on the basic corpus to obtain concurrent execution results; A determining unit is configured to determine a concurrent corpus based on the concurrent execution results, wherein the concurrent corpus includes race-proximity access pairs; wherein the race-proximity access pairs include a first memory access operation and a second memory access operation, the first memory access operation and the second memory access operation occur in different threads, and the memory regions accessed by the first memory access operation and the second memory access operation overlap, and the access time difference between the first memory access operation and the second memory access operation is within a preset threshold range, and at least one of the first memory access operation and the second memory access operation includes a write operation; The second acquisition unit is used to acquire the data competition test results of the target kernel based on the race-proximity access pair.

Images