Concurrent vulnerability verification method and device, electronic equipment and storage medium

Abstract

The application provides a concurrent vulnerability verification method and device, electronic equipment and readable storage medium, applied to the computer kernel security field, including: obtaining a first interleaved sequence in the computer kernel; the first interleaved sequence includes: a plurality of memory operation instructions; the plurality of memory operation instructions executed according to a target condition are used to trigger a concurrent vulnerability; adding a breakpoint before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence and execute; the breakpoint is used to make the memory operation instruction after the breakpoint enter a waiting state; based on the memory operation instruction entering the waiting state and the target condition, the trigger information of the concurrent vulnerability is output. The embodiment adjusts the execution order of the interleaved sequence using the breakpoint, so that the execution process meets the target condition, and solves the problems of expected interleaved sequence execution interference and low reproduction efficiency.

Description

Technical Field

[0001] This application relates to the field of computer kernel security, and more particularly to a method, apparatus, electronic device, and readable storage medium for verifying concurrent vulnerabilities. Background Technology

[0002] The kernel concurrent use-after-free (UAF) vulnerability is a special type of kernel UAF vulnerability caused by improper memory management in a kernel-mode multi-threaded environment.

[0003] Among common kernel concurrency UAF vulnerability detection tools, Segfuzz decomposes complex interleaving stages into multiple interleaving segments and defines interleaving coverage metrics to perceive differences in thread interleaving order. Additionally, Actor generates targeted test cases based on action templates derived from vulnerability characteristics. Its core idea is to define nine types of error templates using a domain-specific language and dynamically capture memory operations based on KASAN instrumentation, orchestrating system call sequences based on these templates.

[0004] However, the aforementioned existing technologies suffer from problems such as interference with the expected interleaved sequence execution and low reproducibility. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for verifying concurrent vulnerabilities, in order to solve the problems of interference with the execution of expected interleaved sequences and low reproduction efficiency in the prior art.

[0006] In a first aspect, embodiments of this application disclose a method for verifying concurrency vulnerabilities. The method includes: obtaining a first interleaved sequence in a computer kernel; the first interleaved sequence includes: multiple memory operation instructions; multiple memory operation instructions executed according to target conditions are used to trigger a concurrency vulnerability; adding breakpoints before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence and executing it; the breakpoints are used to cause memory operation instructions after the breakpoints to enter a waiting state; based on the memory operation instructions entering the waiting state and the target conditions, outputting triggering information for the concurrency vulnerability.

[0007] Secondly, embodiments of this application disclose a verification device for concurrency vulnerabilities, comprising: an acquisition module, configured to acquire a first interleaved sequence in a computer kernel; the first interleaved sequence includes: multiple memory operation instructions; the multiple memory operation instructions executed according to target conditions are used to trigger a concurrency vulnerability; an execution module, configured to add breakpoints before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence and execute it; the breakpoints are used to cause memory operation instructions after the breakpoints to enter a waiting state; and a triggering module, configured to output triggering information for the concurrency vulnerability based on the memory operation instructions entering the waiting state and the target conditions.

[0008] Thirdly, embodiments of this application also provide an electronic device, including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method of the first aspect.

[0009] Fourthly, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method of the first aspect.

[0010] In this embodiment, after obtaining the first interleaved sequence in the computer kernel based on the concurrent execution characteristics of the concurrency vulnerability, breakpoints are added before each memory operation instruction in the first interleaved sequence to facilitate adjustment of the execution order when deviations occur, thus obtaining a second interleaved sequence. When deviations occur during the execution of the second interleaved sequence, breakpoints are used to adjust the execution order of each memory operation instruction during the execution of the second interleaved sequence, further eliminating deviations in the execution result of the second interleaved sequence caused by distortions and interference from various runtime states in the computer kernel.

[0011] After multiple memory operation instructions that had entered a waiting state resume execution, if the target conditions are not met, breakpoints are used to adjust the execution order of each memory operation instruction in the second interleaved sequence. This ensures that the execution order of each memory operation instruction in the waiting state of the second interleaved sequence conforms to the target conditions. Resuming the execution of each memory operation instruction in the second interleaved sequence then successfully obtains the triggering information for the concurrency vulnerability. By adjusting the execution order of memory operation instructions in the second interleaved sequence that deviates from the expected execution order, the adjusted execution sequence matches the triggering characteristics of the concurrency vulnerability, thus stably triggering the vulnerability and increasing the probability of reproducing it. Using breakpoints to adjust the execution order of each memory operation instruction, ensuring that the execution order follows the target conditions, solves the problems of interference with the expected interleaved sequence execution and low reproduction efficiency, facilitating subsequent vulnerability repair, verification, and other related operations.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0013] Figure 1 This is a schematic diagram illustrating the triggering principle of a concurrency vulnerability in an embodiment of this application; Figure 2 This is a flowchart illustrating the steps of a concurrent vulnerability verification method provided in an embodiment of this application. Figure 3 This is a flowchart illustrating the steps of another concurrent vulnerability verification method provided in this application embodiment; Figure 4 This is a schematic diagram of a red-black tree in an embodiment of this application; Figure 5 This is a schematic diagram of the instruction address and function call stack related to a concurrency vulnerability in an embodiment of this application; Figure 6 This is a schematic diagram illustrating an embodiment of the present application for adjusting the execution order of memory operation instructions; Figure 7 This is a flowchart illustrating the steps of another concurrent vulnerability verification method provided in this application embodiment; Figure 8 This is a schematic diagram of a tool for reproducing concurrency vulnerabilities provided in an embodiment of this application; Figure 9 This is a flowchart illustrating the operation of a tool for reproducing concurrency vulnerabilities provided in an embodiment of this application. Figure 10This is a block diagram of a concurrent vulnerability verification device provided in an embodiment of this application; Figure 11 This is a block diagram of an electronic device provided in an embodiment of this application; Figure 12 These are schematic diagrams of the server structure in some embodiments provided in this application. Detailed Implementation

[0014] The technical solutions of the embodiments 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.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0016] The following description, in conjunction with the accompanying drawings and specific embodiments, provides further illustrative examples of the concurrent vulnerability verification method and apparatus of this application.

[0017] Combining Table 1 and Figure 1 Taking the concurrent User-Avoidance (UAF) vulnerability CVE-2023-52772 as an example, this paper explains the principle of triggering a concurrent UAF vulnerability. CVE-2023-52772 is a concurrent UAF vulnerability located in the net / unix module of the computer kernel. As shown in Table 1, the sending thread is queue_oob, and the receiving thread is unix_stream_recv_urg.

[0018] At time U1, the receiving thread executes the `unix_state_lock(sk)` instruction, acquiring the lock. Next, at time U2, the receiving thread executes the instruction `oob_skb=u->oob_skb`, reading the pointer `oob_skb` pointing to a certain memory address into its own local variable. Then, at time U3, the receiving thread executes the instruction `unix_state_unlock(skb)`, releasing the lock.

[0019]

[0020] Table 1 contains instructions related to vulnerability CVE-2023-52772.

[0021] At time F3, which is the gap between when the receiving thread releases the lock but before executing the data-using instruction `state->recv_actor(oob_skb,...)` corresponding to time U4, the sending thread `queue_oob` is scheduled for execution. The sending thread acquires the pointer `skb` and executes the instruction `consume_skb(ousk->oob_skb)` at time F3. The `consume_skb` instruction modifies the data at the memory address pointed to by the pointer `oob_skb`. This may result in the memory address pointed to by `oob_skb` being immediately released, and the memory it occupies being returned to the kernel memory allocator for other uses.

[0022] At time U4, the scheduler switches back to the receive thread. The receive thread executes the `state->recv_actor(oob_skb,...)` instruction, attempting to process the memory address pointed to by the previously saved `oob_skb` pointer. However, this pointer may now be a dangling pointer, meaning the memory address it points to has been freed and may contain: dangerous data that could cause a kernel crash; or it may store a value at a completely different memory address (potentially leading to data corruption, privilege escalation, or other serious security issues).

[0023] like Figure 1 As shown, combined with Figure 1 A brief explanation of how concurrency vulnerabilities are triggered: In the first stage, a random user thread in the kernel... ALLOC was executed The instruction, that is, a pointer p is allocated in memory. In the second phase, the user thread executes the instruction ASSIGN <t, p> within the lock, causing the pointer p to point to an object of type t. In the third phase, the user thread executes the instruction FREE The instruction, which is to release pointer p, is ALLOC. The instruction is executed, and pointer p is allocated to a different memory address (a random process; it's unknown which new memory address it will point to). Fourth stage, user thread. Execute USE <t>Instructions, User Threads At this point, the access is to the original memory address pointed to by the pointer p carried in the object type t. However, the memory address pointed to by the pointer p is no longer the original memory address. In this situation, a concurrency vulnerability is triggered.

[0024] Figure 2 The diagram illustrates the steps of a concurrent vulnerability verification method provided in an embodiment of this application. (Refer to...) Figure 2 The method may include the following steps: Step 101: Obtain the first interleaved sequence in the computer kernel.

[0025] The first interleaved sequence includes: multiple memory operation instructions; the multiple memory operation instructions executed according to the target conditions are used to trigger a concurrency vulnerability.

[0026] For example, obtaining the first interleaved sequence in the computer kernel is the first step in reproducing a concurrency vulnerability (specifically, a concurrent User-Avoidance-Failure vulnerability); the first interleaved sequence consists of memory operation instructions. The computer kernel is the lowest level part of the operating system, possessing the highest privileges and allowing direct, secure, and efficient manipulation of the computer's hardware. Through the computer kernel, hardware resources can be managed, such as CPU scheduling, as well as processes and memory management, such as creating, terminating, and scheduling running processes and threads. The computer kernel plays a crucial role in the computer's operation. Memory operation instructions are instructions that, through the operating system (computer kernel), directly perform operations such as releasing, retrieving, or allocating data stored at specific memory addresses in the computer's underlying hardware. Releasing related memory operation instructions and retrieving related memory operation instructions (used to modify data at memory addresses, etc.) can trigger a concurrent User-Avoidance-Failure vulnerability in a specific scenario.

[0027] Theoretically, a concurrency vulnerability can be triggered when these memory operation instructions are executed in the computer kernel according to the target conditions. The target conditions are characteristics such as the specific order of execution of the relevant memory operation instructions when the concurrency vulnerability is triggered. Taking a concurrent User-Avoidance (UAF) vulnerability as an example, if the first interleaved sequence contains a memory operation instruction for freeing data at a memory address and a memory operation instruction for accessing data at a memory address, and the two memory operation instructions correspond to different threads, and the thread corresponding to the memory operation instruction for accessing the memory address can still access the memory address, then if the memory operation instruction for freeing the memory address is executed again according to the target conditions—that is, the memory operation instruction for freeing the memory address is executed first, and the memory operation instruction for accessing the memory address is executed later—a concurrent UAF vulnerability can be triggered again.

[0028] Step 102: Add a breakpoint before each memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence and execute it.

[0029] The breakpoint is used to cause memory operation instructions following the breakpoint to enter a waiting state.

[0030] For example, theoretically, after obtaining the first interleaved sequence, controlling its execution within the computer kernel according to the target conditions could trigger a concurrency vulnerability again. However, considering that the execution of the first interleaved sequence within the computer kernel is subject to distortions and interference from various runtime states, such as lock contention, interrupt handling, and switching between user and kernel modes, the execution of the threads corresponding to memory operation instructions can be disrupted. This can cause the actual execution order of memory operation instructions within the first interleaved sequence to deviate from the expected order (i.e., the threads executing memory operation instructions are affected and do not execute as expected). This could lead to situations where the concurrency vulnerability cannot be triggered again or triggers unstablely. A thread is an independent execution flow within the computer kernel, used to execute computer instructions, and is the basic unit of scheduling and allocation by the computer kernel (operating system).

[0031] The first interleaved sequence is processed to eliminate distortions and interference in various runtime states within the computer kernel, thus mitigating the impact on the process of triggering concurrent vulnerabilities. Specifically, breakpoints are added before multiple memory operation instructions in the first interleaved sequence, each causing subsequent memory operation instructions to enter a waiting state. Breakpoints are special markers set in the program code by a debugger. Their function is to automatically pause execution and return control to the debugger when the program reaches the breakpoint. At this point, the developer can inspect and analyze the program's state. Breakpoints can be categorized by their implementation mechanism, such as software breakpoints and hardware breakpoints. The breakpoints used in this application refer to hardware breakpoints. Hardware breakpoints are debug points directly monitored by the processor's hardware circuitry. Breakpoint conditions are set in the chip's internal debug registers, allowing the hardware to directly monitor program execution. Unlike software breakpoints, hardware breakpoints do not modify the target program's instruction code; breakpoint detection is entirely implemented by hardware. When a thread in the computer kernel reaches a (hardware) breakpoint, the thread immediately enters a waiting state. Add breakpoints before each memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence. In this way, if the execution of memory operation instructions deviates during the execution of the second interleaved sequence, breakpoints can be used to adjust the execution of the thread corresponding to the memory operation instruction so that the second interleaved sequence executes according to the target conditions, which can further trigger concurrency vulnerabilities.

[0032] Step 103: Based on the memory operation instruction that enters the waiting state and the target condition, output the trigger information for the concurrency vulnerability.

[0033] For example, after all memory operation instructions in the second interleaved sequence have entered the waiting state through their corresponding breakpoints, it is necessary to determine whether the execution order of each memory operation instruction meets the target condition after the memory operation instructions in the waiting state resume execution. For one type of concurrent UAF vulnerability, the target condition is: one thread executes a memory operation instruction to release the same memory address before another thread executes a memory operation instruction to call the same memory address. For example, threads A and B both obtain a pointer p pointing to memory address M. Both threads A and B can operate on pointer p to perform corresponding operations on the data stored at memory address M; pointer p represents memory address M. After a period of time, thread A releases pointer p, and the memory manager in the computer kernel immediately reallocates the memory address pointed to by pointer p. During this period, thread B is unaware that the memory address pointed to by pointer p has been reallocated (the value corresponding to this memory address has likely changed). If thread B then operates on pointer p, it reads an incorrect value, triggering a concurrent UAF vulnerability. Detecting whether the memory operation instructions that entered the waiting state meet the target conditions essentially involves checking the execution order of multiple threads corresponding to these instructions after they resume execution to see if it meets the target conditions. Specifically, one thread must execute a memory operation instruction to release the same memory address before another thread executes an instruction to call the same memory address. If the execution order of each memory operation instruction meets the target conditions—that is, one thread executes the instruction to release the same memory address before another thread executes the instruction to call the same memory address—this meets the triggering logic of a concurrency vulnerability, successfully triggering it and allowing for its verification.

[0034] When the execution order of each memory operation instruction does not meet the target condition—that is, when one thread executes a memory operation instruction to release the same memory address without precedence by another thread executing a memory operation instruction to call the same memory address—this does not conform to the triggering principle of a concurrency vulnerability, and therefore cannot be triggered to reproduce the vulnerability. However, even when the execution order of each memory operation instruction does not meet the target condition, by adjusting the execution order of multiple memory operation instructions—that is, adjusting the execution order of the multiple threads corresponding to the memory operation instructions—to make the execution order of multiple memory operation instructions conform to the target condition, the concurrency vulnerability can still be triggered, and this concurrency vulnerability can be verified.

[0035] In this embodiment, after obtaining the first interleaved sequence in the computer kernel based on the concurrent execution characteristics of the concurrency vulnerability, breakpoints are added before each memory operation instruction in the first interleaved sequence to facilitate adjustment of the execution order when deviations occur, resulting in a second interleaved sequence. When deviations occur during the execution of the second interleaved sequence, breakpoints are used to adjust the execution order of each memory operation instruction in the second interleaved sequence, eliminating deviations in the execution result of the second interleaved sequence caused by distortions and interference from various runtime states in the computer kernel. This allows for adjustment of the execution order of each memory operation instruction in the second interleaved sequence when the execution of memory operation instructions in the waiting state no longer meets the target conditions. Once the execution order of each memory operation instruction in the second interleaved sequence in the waiting state meets the target conditions, the execution of each memory operation instruction in the second interleaved sequence can be resumed. This ensures that the triggering information for the concurrency vulnerability can be successfully obtained, increasing the probability of reproducing the concurrency vulnerability. By using breakpoints to adjust the execution order of each memory operation instruction, the execution order of each memory operation instruction is made to follow the target conditions. This solves the problem of interference with the expected interleaved sequence execution and low reproduction efficiency, and facilitates subsequent vulnerability patching operations.

[0036] Figure 3 This is an embodiment of another concurrent vulnerability verification method provided in this application, see reference. Figure 3 The method in this embodiment may include the following steps: Step 201: Obtain the first interleaved sequence in the computer kernel.

[0037] The first interleaved sequence includes: multiple memory operation instructions; the multiple memory operation instructions executed according to the target conditions are used to trigger a concurrency vulnerability.

[0038] Step 201 can be referred to step 101 above, and will not be repeated here.

[0039] Optionally, step 201 may also include sub-steps 2011-2013: Sub-step 2011: Obtain all memory operation instructions in the computer kernel.

[0040] Sub-step 2012: Filter all memory operation instructions to obtain memory release operation instructions and memory call operation instructions; and construct the memory release operation instructions and the memory call operation instructions into an instruction pair.

[0041] In this instruction pair, the memory release operation instruction and the memory call operation instruction correspond to different threads; the memory release operation instruction is executed before the memory call operation instruction; the memory release operation instruction and the memory call operation instruction operate on the same memory address.

[0042] Optionally, sub-step 2012 may also include sub-steps A1-A2: Sub-step A1: Use a search tree to store all the memory operation instructions.

[0043] All of the memory operation instructions include memory release instructions, memory call instructions, and other memory operation instructions.

[0044] Sub-step A2: Filter the memory release operation instructions and memory call operation instructions stored in the search tree to obtain the memory release operation instructions and memory call operation instructions included in all memory operation instructions.

[0045] For example, substeps A1-A2 further illustrate the process of filtering all memory operation instructions in substep 2012 to obtain memory release and memory call instructions. Event data related to memory operations during computer kernel runtime is collected, i.e., all memory operation instructions that operate on memory addresses. These memory operation instructions include not only memory release and memory call instructions that meet the target conditions (i.e., characteristics of concurrency vulnerabilities), but also other memory operation instructions that do not meet the characteristics of concurrency vulnerabilities. Because the number of memory operation instructions in the computer kernel is enormous, a high-efficiency search tree, such as a red-black tree, is needed to structure and store all memory operation instructions that operate on memory addresses. A node query mechanism is used to quickly determine memory release and memory call instructions that meet the target conditions (operating on the same memory object / the same memory address), quickly filtering to obtain the key memory operations required for reproducing the concurrency vulnerability, i.e., all memory operation instructions that meet the target conditions, including memory release and memory call instructions. Figure 4 As shown, combined with Figure 4 A simple explanation of the principles of a red-black tree: every node in a red-black tree is colored, either black or red, with the root node being black. A red-black tree is a self-balancing binary search tree that maintains its balance through node coloring rules and rotation operations, ensuring that the longest path length does not exceed twice the shortest path length. This results in a stable time complexity of O(logn) for insertion, deletion, and search operations, demonstrating excellent operational efficiency.

[0046] For example, in the process of collecting memory operation event information in a multi-threaded environment within the computer kernel, a globally visible red-black tree, ALLOC_BB, is maintained in the kernel. Each node in the red-black tree consists of the address (addr) and size (size) of a memory object, which is the size of the data stored at that memory address. When a thread performs a memory operation (call) event, the computer kernel stores the address and size of the memory object related to the memory operation as a red-black tree node through the record_event() function. When a memory release event occurs, the corresponding memory object is removed from the red-black tree, ensuring that the information stored in the red-black tree is always consistent with the actual memory allocation and avoiding interference from invalid data. When a memory access event occurs, irrelevant memory operation events are filtered out by searching through the red-black tree nodes. In multi-threaded concurrent execution scenarios, multiple threads may access the red-black tree ALLOC_BB simultaneously. To ensure data consistency, a global lock mechanism is used for synchronization control.

[0047] During the collection of memory operation event information, it is necessary to calculate the instruction address corresponding to the memory operation event. The addr2line tool (used to convert memory addresses in a program into corresponding source code files and line numbers) can be used to determine whether the address on the stack falls within the target function (such as kfree() - a release instruction, __asan_load() - a check instruction, etc.) to identify the instruction address. The following section uses the vulnerability CVE-2024-49903 as an example to detail the process of calculating the memory operation instruction address.

[0048] Figure 5 This demonstrates the instruction address and detailed function call stack information for the dbUnmount() function call in the concurrency vulnerability CVE-2024-49903. For example... Figure 5 As shown, the `dbUnmount()` function calls the `kfree()` function, which is related to memory release operations, at address `ffffffff818de914`. During a function call, the address of the instruction following the memory operation instruction is pushed onto the stack, specifically `ffffffff818de919`. The Actor inserts the `record_event()` function into the `kasan_slab_free()` function, and then records memory operation event information by calling `record_event()`, while simultaneously saving the function call stack information at that moment. When calculating instruction information, the addr2line tool is used to analyze that the instruction ffffffff81454acf is located inside the function kfree(). This indicates that the instruction ffffffff818de919 preceding the instruction ffffffff81454acf in the function call stack is pushed onto the stack when the function kfree() is called. Therefore, the instruction preceding ffffffff818de919, namely ffffffff818de914, calls the kfree() function. Finally, the address of the memory release operation instruction is found to be ffffffff818de914.

[0049] Sub-step 2013: Determine the first interleaved sequence according to the instruction pair.

[0050] For example, substeps 2011-2013 further explain the process of filtering all memory operation instructions mentioned in step 201. Obtaining the first interleaved sequence in the computer kernel that can trigger concurrency vulnerabilities is an important foundation for reproducing concurrency vulnerabilities. Specifically, this includes filtering all memory operation instructions obtained from the computer kernel. During the filtering process, the characteristics of the concurrency vulnerability itself must be considered. Specifically, the memory release and memory call instructions among the filtered memory operation instructions must correspond to different threads; the threads corresponding to the memory release and memory call instructions must each access the same memory address; and the memory release instruction must be executed before the memory call instruction. Only memory release and memory call instructions that meet these characteristics are likely to trigger the concurrency vulnerability in the computer kernel as expected after execution.

[0051] Both memory release and memory access instructions belong to the category of memory manipulation instructions. Memory release instructions are used to free memory addresses. After being released, the memory address is allocated to other processes or threads that need to use it. For example, the `free(&addr)` instruction in C can release the memory address corresponding to `&addr`. Memory access instructions, on the other hand, are a collective term for instructions that perform operations such as modifying, reading, and copying memory addresses. Considering the characteristics of concurrency vulnerabilities, the specific (i.e., unique) function of a memory access instruction can be unrestricted. Any operation—modifying, reading, or copying—on a memory address that poses a concurrency vulnerability risk could potentially trigger a concurrency vulnerability.

[0052] After identifying several memory operation instructions (at least including memory release and memory call instructions) that meet the criteria based on the characteristics of concurrency vulnerabilities, these memory release and memory call instructions are constructed into instruction pairs to facilitate the execution of subsequent memory operation instructions. Using "release-call of the same memory object" as the core filtering condition, instruction pairs matching the triggering characteristics of concurrency vulnerabilities are identified from regular test programs, ensuring that the instruction pairs possess the basic timing logic for vulnerability triggering.

[0053] Step 202: Add a breakpoint before each memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence and execute it.

[0054] The breakpoint is used to cause memory operation instructions following the breakpoint to enter a waiting state.

[0055] Step 202 can be referred to step 102 above, and will not be repeated here.

[0056] Optionally, step 202 may also include sub-steps 2021-2022: Sub-step 2021: Add a breakpoint before each memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence.

[0057] Optionally, sub-step 2021 may also include sub-steps B1-B2: Sub-step B1: Detect whether a target breakpoint exists in the computer kernel and obtain the detection status; the detection status includes whether a target breakpoint exists or not.

[0058] The target breakpoint is used to characterize the unexecuted breakpoints left in the computer kernel.

[0059] Sub-step B2: When the detection condition indicates the existence of a target breakpoint, clear the target breakpoint currently existing in the computer kernel.

[0060] For example, before adding a breakpoint before each memory operation instruction in the first interleaved sequence, it is necessary to check whether any previously set breakpoints (hardware breakpoints) remain in the computer kernel. Because hardware breakpoints are set at the hardware level, they are not automatically cleared as the test program changes; remaining breakpoints are highly likely to affect the testing process for triggering concurrency vulnerabilities. To ensure that the testing process for triggering concurrency vulnerabilities is not interfered with by other factors, it is necessary to clear any existing breakpoints in the computer kernel to ensure that the testing process for triggering concurrency vulnerabilities is as successful as possible.

[0061] Sub-step 2022: Determine the test program based on the second interleaved sequence and the preset test program template, and execute the test program.

[0062] The preset test program template includes a program for executing the memory operation instructions and breakpoints.

[0063] For example, substeps 2021-2022 further explain the process of executing the second interleaved sequence in step 202. To facilitate adjusting the execution sequence of memory operation instructions in case of deviations, breakpoints are added before each memory operation instruction in the first interleaved sequence, resulting in a second interleaved sequence containing both memory operation instructions and breakpoints. For example, the first interleaved sequence includes memory operation instructions a, b, and c, denoted as [a,b,c]; breakpoint x is added before each memory operation instruction in the first interleaved sequence [a,b,c], resulting in the second interleaved sequence [x,a,x,b,x,c]. The second interleaved sequence, obtained by adding breakpoints to the first interleaved sequence, only contains breakpoints and several memory operation instructions, and obviously cannot be run directly. To run the second interleaved sequence, a test program that can run the memory operation instructions and breakpoints in the second interleaved sequence needs to be generated using a preset test program template. The preset test program template includes a program for executing the memory operation instructions and breakpoints. It is a framework responsible for receiving the second interleaved sequence, converting it into a stable and repeatable concurrent test load on real hardware, and cooperating with an external scheduler (such as one based on hardware breakpoints) to achieve instruction-level precision control. It is used to systematically generate and execute test programs for concurrent vulnerabilities related to the second interleaved sequence, and analyze the triggering results of concurrent vulnerabilities after the test programs are run.

[0064] The memory operation instructions include memory release instructions and memory call instructions; the memory release instructions correspond to the first thread, and the memory call instructions correspond to the second thread.

[0065] Optionally, step 202 may also include sub-steps 2023-2024: Sub-step 2023: Obtain the target processor number.

[0066] The target processor number is used to identify the number of the logical processor with the lowest occupancy in the computer kernel.

[0067] Sub-step 2024: Control the first thread to execute the memory release operation instruction in the logic processor, and the second thread to execute the memory call operation instruction in the logic processor, so that the first thread and the second thread are bound to the logic processor.

[0068] For example, before adding breakpoints before each memory operation instruction in the first interleaved sequence, it's necessary to bind the first thread corresponding to the memory release instruction and the second thread corresponding to the memory call instruction in the first interleaved sequence to a processor core. This is because thread scheduling in modern operating systems is inherently probabilistic and unpredictable. That is, it's uncertain whether the first and second threads will ultimately execute the test program to trigger the concurrency vulnerability during the reproduction process. In this case, binding the first and second threads to a specific processor core is not simply about specifying their execution location, but rather about creating a controlled test environment for reproducing the concurrency vulnerability. By specifying that the first and second threads execute their corresponding test programs on the target processor with the lowest CPU usage in the computer kernel, where there is relatively little interference, the thread execution is controlled to minimize interference from various irrelevant runtime states within the computer kernel during the reproduction process, thereby improving the success rate of reproducing the concurrency vulnerability.

[0069] The memory operation instructions include memory release instructions and memory call instructions; the target condition is used to indicate that the memory release instructions are executed before the memory call instructions; the memory release instructions and the memory call instructions correspond to different threads, and the memory release instructions and the memory call instructions operate on the same memory address.

[0070] Step 203: When the memory operation instruction that has entered the waiting state satisfies the target condition, resume the execution of the memory operation instruction and output the trigger information for the concurrency vulnerability.

[0071] For example, when the memory operation instruction entering the waiting state meets the target condition, that is: the memory release instruction and the memory call instruction correspond to different threads, the memory release instruction and the memory call instruction operate on the same memory address, and after both are resumed, the memory release instruction is executed before the memory call instruction. If the condition for triggering the concurrency vulnerability is met, as long as the execution of the thread corresponding to the memory release instruction and the thread corresponding to the memory call instruction are resumed respectively, the memory release instruction will be executed before the memory call instruction, thereby triggering the concurrency vulnerability.

[0072] Optionally, step 203 may also include sub-steps 2031-2034: Sub-step 2031: Based on the breakpoint before the memory release operation instruction, cause the memory release operation instruction to enter the waiting state; Sub-step 2032: When the memory operation instruction following the memory release operation instruction that enters the waiting state is a memory call operation instruction, determine that the memory release operation instruction that enters the waiting state satisfies the target condition, and resume the execution of the memory release operation instruction; Sub-step 2033: Based on the breakpoint before the memory call operation instruction, cause the memory call operation instruction to enter the waiting state; Sub-step 2034: When the instruction preceding the memory operation instruction that enters the waiting state is a memory release instruction, determine that the memory operation instruction that enters the waiting state meets the target condition, resume the execution of the memory operation instruction, and output the trigger information for the concurrency vulnerability.

[0073] For example, substeps 2031-2034 further explain the process in step 203 where, when the memory operation instruction meets the target condition, the execution of the memory operation instruction is resumed to trigger the concurrency vulnerability. When the thread corresponding to the memory release instruction reaches the breakpoint corresponding to the memory release instruction, causing the memory release instruction to enter a waiting state, the subsequent memory operation instruction is checked; if the subsequent memory operation instruction is a memory call instruction, then the memory release instruction has met the target condition, and its execution can be resumed.

[0074] When the thread corresponding to the memory operation instruction reaches the breakpoint corresponding to the memory operation instruction and causes the memory operation instruction to enter a waiting state, the previous memory operation instruction is checked. If the previous memory operation instruction is a memory release instruction, the memory operation instruction also meets the target condition and can be allowed to resume execution.

[0075] The resumption of execution of memory release and memory call instructions can ultimately trigger a concurrency vulnerability. This is because the relative execution order between the threads corresponding to the memory release and memory call instructions is not disturbed. The concurrency vulnerability can be triggered without adjusting the execution order between the memory release and memory call instructions.

[0076] The memory operation instructions include memory release instructions and memory call instructions; the target condition is used to indicate that the memory release instructions are executed before the memory call instructions; the memory release instructions and the memory call instructions correspond to different threads, and the memory release instructions and the memory call instructions operate on the same memory address.

[0077] Step 204: When the memory operation instruction entering the waiting state does not meet the target condition, adjust the execution order of the memory operation instruction according to the target condition, resume the execution of the memory operation instruction, and output the trigger information for the concurrency vulnerability.

[0078] For example, if the memory operation instruction entering the waiting state does not meet the target condition, that is: the memory release instruction and the memory call instruction correspond to different threads, the memory release instruction and the memory call instruction operate on the same memory address, but after both resume execution, the memory release instruction is executed after the memory call instruction. If the conditions for triggering the concurrency vulnerability are not met, the execution order of the memory release instruction and the memory call instruction needs to be adjusted.

[0079] To achieve the target condition that the memory release instruction executes before the memory call instruction, breakpoints need to be used to put both the thread corresponding to the memory release instruction and the thread corresponding to the memory call instruction into a waiting state. This allows the thread corresponding to the memory release instruction to resume execution first, and then the thread corresponding to the memory call instruction to resume execution after the memory release instruction resumes. This ensures that the memory release instruction, after its resumption, executes before the memory call instruction, which in turn resumes execution. For example, the memory release instruction 'a' for thread A enters a waiting state after the memory call instruction 'b' for thread B. However, without adjusting the order of resumption between memory release instruction 'a' and memory call instruction 'b', the characteristics of a concurrency vulnerability are not met, and the vulnerability cannot be verified. Therefore, the execution order of memory release instruction 'a' for thread A and memory call instruction 'b' for thread B is adjusted so that memory release instruction 'a' for thread A resumes execution before memory call instruction 'b' for thread B, thus meeting the characteristics of a concurrency vulnerability. After this adjustment, the execution of both the memory release instruction and the memory call instruction still satisfies the target condition, triggering the concurrency vulnerability.

[0080] Optionally, step 204 may also include sub-steps 2041-2043: Sub-step 2041: Based on the breakpoint before the memory operation instruction, cause the memory operation instruction to enter the waiting state; Sub-step 2042: When the memory operation instruction that enters the waiting state is a memory release operation instruction, and the subsequent memory operation instruction is not a memory call operation instruction, it is determined that the memory operation instruction that enters the waiting state does not meet the target condition; the breakpoint is used to cause the target memory call operation instruction after the memory release operation instruction to enter the waiting state.

[0081] Sub-step 2043: After adjusting the order of instructions according to the order of executing the memory release operation instruction first and then the target memory call operation instruction, resume the execution of the memory release operation instruction and the target memory call operation instruction; and output the trigger information for the concurrency vulnerability.

[0082] For example, sub-steps 2041-2043 describe the process in step 204 where, when a memory operation instruction does not meet the target condition, the execution order of memory operation instructions is adjusted according to the target condition to trigger a concurrency vulnerability. When the thread corresponding to the memory release instruction reaches a breakpoint, causing the memory release instruction to enter a waiting state, and the memory operation instruction following the memory release instruction is not a memory call instruction, meaning there are several memory release instructions between the memory release instruction and the memory call instruction following it, a breakpoint is used to cause a target memory call instruction following the memory release instruction to enter a waiting state. After adjusting the instruction order so that the memory release instruction is executed first, followed by the target memory call instruction, the execution of the memory release instruction and the target memory call instruction is restored, ensuring that the execution of both the memory release instruction and the target memory call instruction satisfies the target condition. After the memory release instruction and the target memory call instruction are executed according to the target condition, a concurrency vulnerability is triggered.

[0083] Optionally, step 204 may also include substeps 2044-2046: Sub-step 2044: Based on the breakpoint before the memory operation instruction, cause the memory operation instruction to enter the waiting state; Sub-step 2045: When the memory operation instruction entering the waiting state is a memory call instruction, and the preceding memory operation instruction is not a memory release instruction, it is determined that the memory call instruction entering the waiting state does not meet the target condition; the breakpoint is used to cause a target memory release instruction preceding the memory call instruction to enter the waiting state. Sub-step 2046: After adjusting the order of instructions according to the order of executing the memory release operation instruction first and then the target memory call operation instruction, resume the execution of the target memory release operation instruction and the memory call operation instruction; and output the trigger information for the concurrency vulnerability.

[0084] For example, substeps 2044-2046 describe the process of adjusting the execution order of memory operation instructions to trigger a concurrency vulnerability when another memory operation instruction in step 204 does not meet the target condition. When the thread corresponding to the memory operation instruction reaches a breakpoint, causing the memory operation instruction to enter a waiting state, and the memory operation instruction preceding the memory operation instruction is not a memory release instruction, that is, there are several memory operation instructions between the memory operation instruction and the memory release instruction preceding it. In this case, a breakpoint is used to cause the target memory release instruction preceding the memory operation instruction to enter a waiting state. After adjusting the instruction order to execute the memory release instruction first and then the target memory operation instruction, the execution of the memory release instruction and the target memory operation instruction is resumed, so that the execution of both the memory release instruction and the target memory operation instruction satisfies the target condition. After the memory release instruction and the target memory operation instruction are executed according to the target condition, the concurrency vulnerability is triggered.

[0085] The core characteristic of memory operation instructions failing to meet the target conditions is that the execution speed of the thread corresponding to the memory release instruction lags behind the execution speed of the thread corresponding to the memory call instruction. This results in the timing of the thread corresponding to the memory release instruction executing the memory release instruction being later than the timing of the thread corresponding to the memory call instruction executing the memory call instruction. Breakpoints can be used to adjust the timing of the thread corresponding to the memory release instruction executing the memory release instruction and the timing of the thread corresponding to the memory call instruction executing the memory call instruction.

[0086] like Figure 6 As shown, in stage (a), the thread that calls the memory operation instruction... Threads corresponding to memory release operation instructions In the pending execution state. (b) Stage, the thread corresponding to the memory operation instruction is called. It is less affected by runtime interference in the computer kernel, and its execution speed is relatively faster compared to the thread corresponding to the memory release operation instructions that are affected by the interference. The execution speed is faster, and it occurs in the thread corresponding to the memory release operation instruction. The corresponding breakpoint was previously triggered, invoking the thread corresponding to the memory operation instruction. Enter a waiting state; in phase (c), Similarly, it enters a waiting state instead of continuing execution; in phase (d), the thread... and threads After all threads enter the waiting state, adjust the thread. and threads The execution order, that is, the threads Execution resumed first, preemptively executing the memory release instruction. , Still in a waiting state; (e) phase, thread Execution resumed, and then the memory release operation instruction was executed. This way, you can use breakpoints to control the thread. and threads The execution order is adjusted; finally, in stage (f), breakpoints can be used to adjust the timing of when the thread corresponding to the memory release instruction executes the memory release instruction and when the thread corresponding to the memory call instruction executes the memory call instruction. After adjustment, the thread corresponding to the memory call instruction... Threads corresponding to memory release operation instructions The concurrency vulnerability was successfully triggered. Breakpoints were used to adjust the execution order of each memory operation instruction so that the execution order of each memory operation instruction was executed according to the target conditions. This solved the problem of interference with the expected interleaved sequence execution and low reproduction efficiency, and facilitated subsequent vulnerability patching operations.

[0087] Optionally, after step 202 and before steps 203 and 204, sub-steps C1-C2 may also be included: Sub-step C1: Detect the execution status of the breakpoints before the memory release operation instruction and the breakpoints before the memory call operation instruction, respectively; Sub-step C2: If, within the preset target duration, no breakpoint is detected before the first thread executes the memory release operation instruction, or no breakpoint is detected before the second thread executes the memory call operation instruction, the second interleaved sequence is re-executed.

[0088] For example, steps 203 and 204 discuss whether the execution of the thread corresponding to the memory release instruction and the thread corresponding to the memory call instruction can meet the target conditions. Both threads will execute to their respective breakpoints. Substeps C1-C2 further explain the situation where the threads corresponding to the memory release instruction or the memory call instruction fail to execute to their breakpoints due to interference from the computer kernel.

[0089] The execution of breakpoints by the threads corresponding to memory release instructions and memory call instructions is checked separately. If, within the preset target time, the thread corresponding to the memory release instruction (first thread) is not detected to reach the breakpoint corresponding to the memory release instruction, or the thread corresponding to the memory call instruction (second thread) is not detected to reach the breakpoint corresponding to the memory call instruction, it indicates that the first or second thread has been interfered with by the computer kernel and cannot execute the test program corresponding to the second interleaved sequence in a timely manner. Considering the complexity of computer kernel operation and shortening the time required to reproduce the concurrent vulnerability, the second interleaved sequence is re-executed, so that the interfered first or second thread is called again, ensuring that the corresponding memory operation instructions can be re-executed.

[0090] like Figure 7 As shown, this application also provides an embodiment of another method for verifying concurrent vulnerabilities, which mainly includes a conventional fuzzing phase and a concurrent fuzzing phase.

[0091] In the conventional fuzzing phase, concurrent system call pairs are generated by dynamically sensing key interleaved sequence information and combining them with test cases. These concurrent system call pairs are then used to generate concurrent interleaved sequences. The specific implementation process of dynamically sensing key interleaved sequence information involves first identifying the memory objects that the system calls need to operate on using a memory operation object identification method. These memory objects are then filtered to meet the characteristics / target conditions for triggering concurrency vulnerabilities, including that the memory release instruction executes before the memory call instruction, the memory release and memory call instructions correspond to different threads, and the memory release and memory call instructions operate on the same memory address. Next, a concurrent system call pair construction method is used to identify concurrent system call pairs in the conventional test program. Finally, a concurrent interleaved sequence is generated for each pair of concurrent system call pairs.

[0092] In the concurrent fuzzing phase, all operations are based on the concurrent interleaved sequences generated in the regular fuzzing phase. First, the concurrent interleaved sequences must be combined with the concurrent test program constructor method to generate an executable test program, because the concurrent interleaved sequences themselves cannot be directly executed by the computer kernel. The expected result of running the test program is to directly trigger concurrent vulnerabilities, facilitating subsequent related detection. The concurrent test program constructor method is designed to construct concurrent test programs that can be executed concurrently according to the interleaved sequence during the concurrent fuzzing phase. It also designs a thread instruction-level interleaved execution strategy based on processor breakpoints. This strategy controls the thread switching process and implements the orchestration and execution of the instruction interleaved scheduling sequence, jointly supporting thread interleaved execution.

[0093] Furthermore, during the execution of the test program, unpredictable behaviors such as the action of synchronization primitives or system state changes may cause the actual execution sequence of the test program to fail to execute according to the expected sequence. Therefore, it is necessary to compare the actual execution information during the execution of the test program with the concurrent interleaved sequence generated by the aforementioned interleaved sequence information acquisition method to determine the feedback indicator (i.e., the target interleaved execution state); evaluate whether the system execution state affects the interleaved execution based on the feedback indicator; and determine whether to call the retry mechanism to change the execution strategy based on the evaluation results. By repeatedly executing the test program within a reasonable range, the interference introduced by the system execution state can be reduced, thereby attempting to achieve the expected interleaved execution state and improving the success rate of reproducing concurrent vulnerabilities.

[0094] like Figure 8 As shown in the embodiments of this application, a concurrent vulnerability reproduction tool is also provided. The working principle of the concurrent vulnerability reproduction tool will be introduced below.

[0095] This concurrency vulnerability reproduction tool is based on Syzkaller and improves upon it to trigger and verify concurrency vulnerabilities. Syzkaller employs a modular design, with core components including the control module syz-manager, the execution module syz-executor, and the testing module syz-fuzzer. The syz-manager is the entry point for the entire testing process, running on a stable host kernel, unaffected by test load, and operates within the host machine. The syz-executor interacts with the kernel of the computer being tested, designed for simplicity and minimal interference, and runs in a virtual machine. The syz-fuzzer is responsible for triggering test case generation, mutation, and coverage analysis. Similar to Syzkaller, this concurrency vulnerability reproduction tool's workflow mainly consists of two parts: Regular Fuzzing and Scheduled Fuzzing.

[0096] Conventional fuzz testing mainly includes stages such as concurrent system call pair identification, interleaved timing information generation, and concurrent interleaved sequence construction, specifically including: 1) Add a queue to the syz-manager module to store concurrent inputs (con_inp). Concurrent inputs (con_inp) include interleaved sequences that meet the conditions for triggering concurrency vulnerabilities, including memory operation instructions, such as... Figure 8 The memory access instruction used to access memory addresses. Memory release instructions used to free memory addresses. The `input_queue` is used for efficient transmission and deduplication of concurrent input (`con_inp`). Furthermore, it integrates a series of Remote Procedure Call (RPC) functions for transmitting concurrent input (`con_inp`). These functions provide a standardized and efficient communication mechanism for transmitting concurrent input between different modules, enabling cross-module (transmission between modules such as `syz-manager`, `syz-fuzzer`, and `syz-scheduler`) and cross-environment (instruction transmission between the host and virtual machines) collaboration.

[0097] 2) Add a post-test program execution information collection and analysis step to the syz-fuzzer module. The syz-fuzzer module is responsible for generating and mutating test cases. After the filtering program Pregu, which filters interleaved sequences in the computer kernel, completes execution, the syz-fuzzer module uses information related to memory operations in the computer kernel during Pregu's execution to identify interleaved sequences and concurrent system call pairs, generate thread interleaving information, and generate concurrent inputs. It also adds several RPC functions for concurrent input transmission.

[0098] During the concurrent fuzzing phase, in order to conveniently utilize the concurrent input sent from the syz-fuzzer module to the syz-manager module... _ The concurrent vulnerability reproduction tool provided in this application is an extension of Syzkaller, adding the syz-scheduler module for concurrent fuzzing; and extending the syz-executor module to support interleaved execution of test programs. The syz-executor module is responsible for actually executing the concurrent system call pairs generated by the syz-fuzzer module in the computer kernel. During the code execution of the concurrent system call pairs, code coverage of the concurrent system call pairs is collected by means of compiler instrumentation (a non-intrusive way of collecting program runtime information).

[0099] The working process of the concurrency vulnerability reproduction tool includes: the syz-executor module accepts the concurrent input con_inp, and combines the concurrent input con_inp with the deterministic scheduling concurrent test program template Tshce to construct the concurrent test program Psche. In thread S... _ and thread S _ Before executing system calls (i.e. threads) of the concurrent test program Psche, a thread barrier is set up through syz-executor to enable the two system calls / threads to execute concurrently.

[0100] Through syz-executor, S is called in the system. _ and S _ The hypersystem call `hyper_reset_bp(cpu)` is inserted beforehand to clear untriggered (hardware) breakpoints in the kernel, and the hypersystem call `hyper_set_bp(cpu)` is used to set new (hardware) breakpoints. A hypersystem call is a privileged call interface in which a user thread on the host machine communicates directly with the virtual machine. After setting a hypersystem call, the `syz-manager` module on the host machine and the `syz-executor` module on the virtual machine can directly exchange data; that is, setting a hypersystem call performs relevant settings on the virtual machine's computer kernel. Next, thread S executes the memory release operation instructions. _ and the thread S that executes the memory operation instructions. _ Finally, syz-executor collects the threads S that perform memory release operations via the hypersystem call hyper_check_bp(). _ And the thread S that executes the memory operation instructions. _ The tool executes related thread interleaving feedback information. This concurrency vulnerability reproduction tool defines three supersystem calls to set the installation and restoration order of specified thread breakpoints in user space. These three supersystem calls are shown in Table 2. All three are variants of the custom system call `hypercall()`, differing only in the number of parameters the `hypercall()` function accepts.

[0101]

[0102] Table 2 Implementation of the three supersystem calls In implementation, all three hypersystem calls are variants of the custom system call function hypercall(); the prototype of the custom system call function hypercall(cpu, CMD, bp, sche) is shown in the following code: SYSCALL_DEFINE4(hypercall,unsignedlong,cpu,unsignedlong,cmd,unsignedlong,bp,unsignedlong,sche) { uint64_tret; asmvolatile( "movq%1,%%rax\n\t" "movq%2,%%rbx\n\t" "movq%3,%%rcx\n\t" "movq%4,%%rdx\n\t" "nop\n\t" "movq%%rax,%0\n\t" :"=r"(ret) :"r"(cpu),"r"(cmd),"r"(bp),"r"(sche) : ); returnret; } in ， CMD {SET, RESET, CHECK}, where CMD is the command parameter, and its value is limited to setting a breakpoint (SET), clearing a breakpoint (RESET), and checking a breakpoint (CHECK). The hypercall() function receives user-space input parameters, including the specified vCPU number (cpu), the hypercall command (CMD), the address of the installed breakpoint (bp), and the execution order after breakpoint resumption (sche). After receiving the parameters, the hypercall() function uses assembly language to pass each parameter to a specific register for QEMU to read, while inserting a nop instruction to mark the completion of parameter passing.

[0103] After syz-executor finishes execution, syz-scheduler retrieves information such as coverage and thread interleaving mode feedback from the concurrent test program Psche during execution via shared memory, and determines the next execution strategy based on the thread interleaving mode feedback. Simultaneously, syz-manager adds a corpus, cuaf_corpus, to store concurrent input con_inp. syz-scheduler sends the test program that triggers new code coverage, along with its thread interleaving information, to syz-manager via RPC and saves it to the cuaf_corpus for testing program persistence and fast startup when syz-scheduler connects.

[0104] like Figure 9 As shown, the concurrent fuzzing phase of this concurrent vulnerability reproduction tool consists of six phases, each completed by a specific module. The six phases are: ①Store con_inp, ②Load con_inp, ③Generate Psche, ④ScheExecute Psche, ⑤Collect Feedback, and ⑥Save con_inp.

[0105] The Store con_inp phase is executed by the syz-manager module, and its main function is to obtain concurrent input con_inp.

[0106] The Load con_inp phase is executed by the syz-scheduler module, and its main function is to construct concurrent call pairs based on the concurrent input con_inp.

[0107] The Generate Psche phase is executed by the syz-executor module. Its main function is to receive concurrent call pairs constructed from concurrent input con_inp and populate them with the deterministic scheduling concurrent test program template Tsche to construct the concurrent test program Psche.

[0108] The ScheExecute Psche phase is executed by the syz-executor module, and its main function is to execute the concurrent test program Psche.

[0109] The Collect Feedback phase is executed by the syz-scheduler module. Its main function is to obtain data and information such as coverage and thread interleaving mode feedback during the execution of the concurrent test program Psche through shared memory after the syz-executor finishes executing the concurrent test program Psche, and determine the next execution strategy based on the thread interleaving feedback information.

[0110] The Save con_inp phase is executed by the syz-manager module. Its main function is to receive the test program that triggers new code coverage and its related interleaving information sent by the syz-scheduler module through remote function calls. The syz-manager module saves it to the corpus cuaf_corpus6 for testing program persistence and fast startup when connected to syz-scheduler.

[0111] The concurrency vulnerability reproduction tool provided in this application supports kernel-level thread instruction interleaving execution and is implemented based on QEMU and KVM. The `kvm_cpu_exec()` function is the core function for handling vCPU execution when QEMU and KVM work together. It contains the main execution logic for each vCPU thread, responsible for triggering virtual machine instruction execution and handling exit events. To capture virtual machine breakpoint VMExit events, the concurrency vulnerability reproduction tool provided in this application adds logic for capturing and handling breakpoint VMExit events to the `kvm_cpu_exec()` function, ensuring that QEMU takes over the handling when a virtual machine breakpoint is triggered. After extracting the address of the `nop` instruction in `hypercall()` through disassembly, it is passed to QEMU as the compilation option `HYPEADDR` during compilation. When each vCPU thread starts, QEMU first installs a breakpoint at the `HYPEADDR` address, enabling the `kvm_cpu_exec()` function to detect user-space `hypercall()` calls by handling breakpoint VMExit events. By adjusting the execution order of the input concurrent sequence through breakpoints, the efficiency of concurrency vulnerability reproduction is improved.

[0112] Reference Figure 10 The concurrent vulnerability verification device 50 in this embodiment may include: The acquisition module 501 is used to acquire a first interleaved sequence in the computer kernel; the first interleaved sequence includes: multiple memory operation instructions; the multiple memory operation instructions executed according to the target conditions are used to trigger a concurrency vulnerability.

[0113] Optionally, the acquisition module 501 may also include: The acquisition submodule is used to acquire all memory operation instructions in the computer kernel; A filtering submodule is used to filter all memory operation instructions to obtain memory release instructions and memory call instructions, which are included in all memory operation instructions; and to construct the memory release instructions and the memory call instructions into instruction pairs; the memory release instructions and the memory call instructions in the instruction pairs correspond to different threads; the memory release instructions are executed before the memory call instructions; the memory release instructions and the memory call instructions operate on the same memory address.

[0114] Optionally, the filtering submodule may also include: The storage submodule is used to store all the memory operation instructions using a search tree; all the memory operation instructions include memory release instructions, memory call instructions, and other memory operation instructions. The filtering submodule is used to filter the memory operation instructions and memory call instructions stored in the search tree to obtain all memory operation instructions, including memory release instructions and memory call instructions.

[0115] A determination submodule is used to determine the first interleaved sequence based on the instruction pair.

[0116] The execution module 502 is used to add a breakpoint before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence and execute it; the breakpoint is used to cause the memory operation instructions after the breakpoint to enter a waiting state.

[0117] Optionally, the execution module 502 may also include: Add a submodule to add breakpoints before each first memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence; Optionally, adding submodules may also include: The detection unit is used to detect whether a target breakpoint exists in the computer kernel and obtain the detection status; the detection status includes whether a target breakpoint exists or not; the target breakpoint is used to characterize the unexecuted breakpoints left in the computer kernel; The clearing unit is used to clear the target breakpoint currently existing in the computer kernel when the detection condition is that a target breakpoint exists.

[0118] The determination submodule is used to determine the test program based on the second interleaved sequence and the preset test program template, and to execute the test program; the preset test program template includes a program for executing the memory operation instructions and breakpoints.

[0119] Optionally, the execution module 502 may also include: The acquisition submodule is used to acquire the target processor number; the target processor number is used to identify the number corresponding to the lowest-occupied logical processor in the computer kernel; The control submodule is used to control the first thread to execute the memory release operation instruction in the logic processor and the second thread to execute the memory call operation instruction in the logic processor, so that the first thread and the second thread are bound to the logic processor.

[0120] Trigger module 503 is used to output trigger information for the concurrency vulnerability based on the memory operation instruction that enters the waiting state and the target condition.

[0121] Optionally, the trigger module 503 may also include: The recovery submodule is used to resume the execution of the memory operation instruction when the memory operation instruction that has entered the waiting state meets the target condition, and to output the trigger information for the concurrency vulnerability. Optionally, the recovery submodule may also include: The first waiting unit is used to cause the memory release operation instruction to enter the waiting state based on the breakpoint before the memory release operation instruction; The first determining unit is configured to determine that the memory release operation instruction entering the waiting state satisfies the target condition when the memory operation instruction following the memory release operation instruction entering the waiting state is a memory call operation instruction, and to resume the execution of the memory release operation instruction. The second waiting unit is used to cause the memory call operation instruction to enter the waiting state based on the breakpoint before the memory call operation instruction. The output unit is configured to determine that the memory operation instruction entering the waiting state satisfies the target condition when the instruction preceding the memory operation instruction entering the waiting state is a memory release operation instruction, resume the execution of the memory operation instruction, and output the trigger information for the concurrency vulnerability.

[0122] The adjustment submodule is used to adjust the execution order of the memory operation instructions according to the target conditions when the memory operation instructions entering the waiting state do not meet the target conditions, then resume the execution of the memory operation instructions, and output the trigger information for the concurrency vulnerability.

[0123] Optionally, the adjustment submodule may also include: The third waiting unit is used to cause the memory operation instruction to enter the waiting state based on the breakpoint before the memory operation instruction. The second determining unit is configured to, when the memory operation instruction entering the waiting state is a memory release operation instruction and the subsequent memory operation instruction is not a memory call operation instruction, determine that the memory operation instruction entering the waiting state does not meet the target condition; and use the breakpoint to cause a target memory call operation instruction following the memory release operation instruction to enter the waiting state. The first recovery unit is used to restore the execution of the memory release operation instruction and the target memory call operation instruction by adjusting the instruction order according to the order in which the memory release operation instruction is executed first and the target memory call operation instruction is executed later; and output the trigger information of the concurrency vulnerability.

[0124] Optionally, the adjustment submodule may also include: The fourth waiting unit is used to cause the memory operation instruction to enter the waiting state based on the breakpoint before the memory operation instruction. The third determining unit is configured to, when the memory operation instruction entering the waiting state is a memory call operation instruction and the preceding memory operation instruction is not a memory release operation instruction, determine that the memory call operation instruction entering the waiting state does not meet the target condition; and use the breakpoint to cause a target memory release operation instruction preceding the memory call operation instruction to enter the waiting state. The second recovery unit is used to restore the execution of the target memory release operation instruction and the memory call operation instruction by adjusting the instruction order according to the order in which the target memory release operation instruction is executed first and the memory call operation instruction is executed later; and output the trigger information of the concurrency vulnerability.

[0125] Optionally, the adjustment submodule may also include: The detection unit is used to detect the execution status of the breakpoints before the memory release operation instruction and the breakpoints before the memory call operation instruction, respectively. The execution unit is configured to re-execute the second interleaved sequence if, within a preset target duration, no breakpoint is detected in the first thread before the execution of the memory release operation instruction, or no breakpoint is detected in the second thread before the execution of the memory call operation instruction.

[0126] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0128] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0129] This application provides an electronic device including a memory and one or more programs, wherein the programs are stored in the memory and configured to be executed by one or more processors. The programs include methods for performing one or more of the above embodiments.

[0130] Figure 11 This is a block diagram illustrating an electronic device 800 according to an exemplary embodiment. For example, device 800 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0131] Reference Figure 11 The device 800 may include one or more of the following components: a processing component 802, a memory 804, a power supply component 806, a multimedia component 808, an audio component 810, an input / output (I / O) interface 812, a sensor component 814, and a communication component 816.

[0132] Processing component 802 typically controls the overall operation of device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 802 may include one or more processors 820 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

[0133] Memory 804 is configured to store various types of data to support the operation of device 800. Examples of this data include instructions for any application or method operating on device 800, contact data, phonebook data, messages, pictures, videos, etc. Memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0134] Power supply component 806 provides power to various components of device 800. Power supply component 806 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to device 800.

[0135] Multimedia component 808 includes a screen that provides an output interface between device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When device 800 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0136] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when device 800 is in an operating mode, such as call mode, recording mode, and voice information processing mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

[0137] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0138] Sensor assembly 814 includes one or more sensors for providing state assessments of various aspects of device 800. For example, sensor assembly 814 can detect the on / off state of device 800, the relative positioning of components such as the display and keypad of device 800, changes in the position of device 800 or a component of device 800, the presence or absence of user contact with device 800, the orientation or acceleration / deceleration of device 800, and temperature changes of device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 814 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0139] Communication component 816 is configured to facilitate wired or wireless communication between device 800 and other devices. Device 800 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency information processing (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0140] In an exemplary embodiment, the apparatus 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0141] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of the device 800 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0142] Figure 12 This is a schematic diagram of the server structure in some embodiments of this application. The server 900 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 922 (e.g., one or more processors) and memory 932, and one or more storage media 930 (e.g., one or more mass storage devices) for storing application programs 942 or data 944. The memory 932 and storage media 930 can be temporary or persistent storage. The program stored in the storage media 930 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 922 may be configured to communicate with the storage media 930 and execute the series of instruction operations in the storage media 930 on the server 900.

[0143] Server 900 may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input / output interfaces 958, one or more keyboards 956, and / or one or more operating systems 941, such as Windows Server™, MacOS X™, Unix™, Linux™, FreeBSD™, etc.

[0144] A non-transitory computer-readable storage medium is provided, which, when the instructions in the storage medium are executed by the processor of a device (server or terminal), enables the device to perform the methods of the above embodiments; therefore, further details will not be repeated here. Additionally, the beneficial effects of employing the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments related to this application, please refer to the description of the method embodiments of this application.

[0145] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor can execute the computer instructions, causing the computer device to perform the methods described in the above embodiments. Therefore, these will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated here either. For technical details not disclosed in the computer program product or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application. Those skilled in the art will readily conceive of other embodiments of this application upon considering the specification and practicing the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary technical means in the art not disclosed in this application. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0146] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0147] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0148] The above provides a detailed description of a file marking method, a method for identifying marking information in marked files, and a file identification method provided by this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.< / t>

Claims

1. A method for verifying concurrent vulnerabilities, characterized in that, The method includes: Obtain a first interleaved sequence from the computer kernel; the first interleaved sequence includes: multiple memory operation instructions; multiple memory operation instructions executed according to target conditions are used to trigger a concurrency vulnerability; A breakpoint is added before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence, which is then executed; the breakpoint is used to cause memory operation instructions following the breakpoint to enter a waiting state. Based on the memory operation instruction that enters the waiting state and the target condition, the trigger information for the concurrency vulnerability is output.

2. The method for verifying concurrency vulnerabilities according to claim 1, characterized in that, The method of outputting trigger information for the concurrency vulnerability based on the memory operation instruction that enters the waiting state and the target condition includes: When the memory operation instruction that has entered the waiting state satisfies the target condition, the execution of the memory operation instruction is resumed, and the triggering information for the concurrency vulnerability is output. If the memory operation instruction entering the waiting state does not meet the target condition, the execution order of the memory operation instruction is adjusted according to the target condition, the execution of the memory operation instruction is resumed, and the trigger information for the concurrency vulnerability is output.

3. The method for verifying concurrency vulnerabilities according to claim 1, characterized in that, The step of obtaining the first interleaved sequence in the computer kernel includes: Retrieve all memory operation instructions in the computer kernel; All memory operation instructions are filtered to obtain memory release instructions and memory call instructions; the memory release instructions and memory call instructions are then constructed into instruction pairs; the memory release instructions and memory call instructions in the instruction pairs correspond to different threads; the memory release instructions are executed before the memory call instructions; the memory release instructions and memory call instructions operate on the same memory address. The first interleaved sequence is determined according to the instruction pair.

4. The method for verifying concurrency vulnerabilities according to claim 3, characterized in that, The filtering of all memory operation instructions to obtain memory release and memory recall instructions includes: All memory operation instructions are stored using a search tree; all memory operation instructions include memory release instructions, memory call instructions, and other memory operation instructions. The memory operation instructions stored in the search tree are filtered to obtain all memory operation instructions, including memory release instructions and memory call instructions.

5. The method for verifying concurrency vulnerabilities according to claim 1, characterized in that, The step of adding breakpoints before each memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence and execute it includes: Add breakpoints before each first memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence; The test program is determined and executed based on the second interleaved sequence and the preset test program template; the preset test program template includes a program for executing the memory operation instructions and breakpoints.

6. The method for verifying concurrency vulnerabilities according to claim 2, characterized in that, The memory operation instructions include memory release operation instructions and memory call operation instructions; the target condition is used to indicate that the memory release operation instruction is executed before the memory call operation instruction. The memory release operation instruction and the memory call operation instruction correspond to different threads, and the memory release operation instruction and the memory call operation instruction operate on the same memory address respectively.

7. The method for verifying concurrency vulnerabilities according to claim 6, characterized in that, When the memory operation instruction that has entered the waiting state satisfies the target condition, the execution of the memory operation instruction is resumed, and the triggering information for the concurrency vulnerability is output, including: Based on the breakpoint before the memory release operation instruction, the memory release operation instruction enters the waiting state; When the memory operation instruction following the memory release operation instruction that enters the waiting state is a memory call operation instruction, it is determined that the memory release operation instruction that enters the waiting state satisfies the target condition, and the execution of the memory release operation instruction is resumed. Based on the breakpoint before the memory operation instruction, the memory operation instruction enters the waiting state; If the preceding instruction of the memory operation instruction entering the waiting state is a memory release instruction, it is determined that the memory operation instruction entering the waiting state meets the target condition, the execution of the memory operation instruction is resumed, and the trigger information for the concurrency vulnerability is output.

8. The method for verifying concurrency vulnerabilities according to claim 6, characterized in that, When a memory operation instruction entering the waiting state does not meet the target condition, the execution order of the memory operation instructions is adjusted according to the target condition, the execution of the memory operation instructions is resumed, and trigger information for the concurrency vulnerability is output, including: Based on the breakpoint preceding the memory operation instruction, the memory operation instruction enters the waiting state; When the memory operation instruction that enters the waiting state is a memory release operation instruction, and the subsequent memory operation instruction is not a memory call operation instruction, it is determined that the memory operation instruction that enters the waiting state does not meet the target condition; the breakpoint is used to cause a target memory call operation instruction after the memory release operation instruction to enter the waiting state. After adjusting the instruction order according to the order of executing the memory release operation instruction first and then the target memory call operation instruction, the execution of the memory release operation instruction and the target memory call operation instruction is restored; and the trigger information of the concurrency vulnerability is output.

9. The method for verifying concurrency vulnerabilities according to claim 6, characterized in that, The step of adjusting the execution order of the memory operation instructions according to the target condition when the memory operation instructions entering the waiting state do not meet the target condition, resuming the execution of the memory operation instructions, and outputting the trigger information for the concurrency vulnerability, further includes: Based on the breakpoint preceding the memory operation instruction, the memory operation instruction enters the waiting state; When the memory operation instruction that enters the waiting state is a memory call instruction, and the preceding memory operation instruction is not a memory release instruction, it is determined that the memory call instruction that enters the waiting state does not meet the target condition; the breakpoint is used to cause a target memory release instruction preceding the memory call instruction to enter the waiting state. After adjusting the instruction order according to the order in which the target memory release operation instruction is executed first, followed by the memory call operation instruction, the execution of the target memory release operation instruction and the memory call operation instruction is restored; and the trigger information for the concurrency vulnerability is output.

10. The method for verifying concurrency vulnerabilities according to claim 1, characterized in that, The memory operation instructions include memory release operation instructions and memory call operation instructions; the memory release operation instructions correspond to the first thread, and the memory call operation instructions correspond to the second thread. Before adding breakpoints before each memory operation instruction in the first interleaved sequence, and before obtaining and executing the second interleaved sequence, the process also includes: Obtain the target processor number; the target processor number is used to identify the number corresponding to the lowest-occupied logical processor in the computer kernel; The first thread is controlled to execute the memory release operation instruction in the logical processor, and the second thread is controlled to execute the memory call operation instruction in the logical processor, so that the first thread and the second thread are bound to the logical processor.

11. The method for verifying concurrency vulnerabilities according to claim 5, characterized in that, Before adding breakpoints before each first memory operation instruction in the first interleaved sequence to obtain the second interleaved sequence, the method further includes: The system detects whether a target breakpoint exists in the computer kernel and obtains the detection results; the detection results include whether a target breakpoint exists or not; the target breakpoint is used to characterize unexecuted breakpoints left in the computer kernel. When the detection indicates the existence of a target breakpoint, the target breakpoint currently existing in the computer kernel is cleared.

12. The method for verifying concurrency vulnerabilities according to claim 6, characterized in that, The breakpoint before the memory release operation instruction corresponds to the first thread, and the breakpoint before the memory call operation instruction corresponds to the second thread; Before the execution order of the memory operation instructions is adjusted according to the target condition when the memory operation instructions entering the waiting state do not meet the target condition, the execution of the memory operation instructions is resumed, and the triggering information for the concurrency vulnerability is output, the method further includes: The execution status of the breakpoints before the memory release operation instruction and the breakpoints before the memory call operation instruction are detected respectively; If, within the preset target time, no breakpoint is detected before the first thread executes the memory release operation instruction, or no breakpoint is detected before the second thread executes the memory call operation instruction, the second interleaved sequence is re-executed.

13. A device for verifying concurrent vulnerabilities, characterized in that, The device includes: The acquisition module is used to acquire a first interleaved sequence in the computer kernel; the first interleaved sequence includes: multiple memory operation instructions; the multiple memory operation instructions executed according to the target conditions are used to trigger a concurrency vulnerability; An execution module is used to add breakpoints before each memory operation instruction in the first interleaved sequence to obtain a second interleaved sequence and execute it; the breakpoints are used to cause memory operation instructions after the breakpoints to enter a waiting state; The triggering module is used to output triggering information for the concurrency vulnerability based on the memory operation instruction that enters the waiting state and the target condition.

14. An electronic device, characterized in that, The method includes a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 12.

Images