A kernel fuzzing method based on property interface guidance and related device

Abstract

This application relates to the field of fuzzing technology, and provides a kernel fuzzing method and related equipment guided by feature interfaces. The method includes: obtaining the unique runtime interface information of the target distribution kernel based on the target distribution kernel and its corresponding mainline kernel; generating interface test cases for the target distribution kernel based on the unique runtime interface information using a large language model; obtaining multiple general test cases and determining the priority value of each general test case based on the interface test cases; and performing fuzzing on the target distribution kernel using the priority values ​​of all general test cases to obtain the fuzzing results of the target distribution kernel. The method of this application can improve the effectiveness of fuzzing the distribution kernel and its corresponding mainline kernel.

Description

Technical Field

[0001] This application relates to the field of fuzzing technology, and in particular to a kernel fuzzing method and related equipment guided by a feature interface. Background Technology

[0002] In current research and practice, Linux kernel fuzzing has become an important means of discovering kernel vulnerabilities. A typical solution is to use general-purpose fuzzing tools such as Syzkaller and Healer. Typical tools and core technical ideas are as follows: Syzkaller defines test case rules based on the Syzlang syscall description language, supports pseudo-syscalls to simulate complex calls, and discovers vulnerabilities through coverage guidance; Healer extracts high-frequency syscall patterns from system logs to optimize the initial seed set, and uses relational learning models to analyze the dependencies between syscalls to generate syscall sequences that can deeply explore the state of kernel subsystems; Hybrid Fuzzing on the Linux Kernel combines symbolic execution and fuzzing techniques, and uses constraint solving to generate test cases for low-coverage code paths; Augmenting Kernel Fuzzing with System Call Specification Generation (KSG) uses eBPF technology to dynamically track the parameter types and constraints of syscalls, and then automatically generates syscall description files for specific kernel modules. These tools primarily rely on system call sequence generation and coverage-based bootstrapping to explore kernel code paths, achieving good results in vulnerability discovery within the mainline kernel. However, when directly applied to Linux distribution kernels, they reveal significant shortcomings.

[0003] The main shortcomings are concentrated in the following aspects: There is insufficient testing of the release-specific runtime parameter interface.

[0004] Linux distribution kernels are customized versions of the mainline kernel, containing numerous unique runtime parameter interfaces. Distribution kernel developers typically combine these interfaces with proprietary code or tuning software to support various business scenarios and requirements. This results in significant differences between Linux distribution kernels and the mainline kernel, even though these interfaces are not enabled by default in the mainline kernel. For example, the Ubuntu 22.04 kernel provides 22,592 writable numeric parameter interfaces, 35.2% more than the 16,706 in the corresponding mainline Linux 6.8.12 kernel. These runtime parameter interfaces usually exist as files in the / sys or / proc / sys directories, and their parameter values ​​affect the kernel's execution path.

[0005] These distribution-specific interfaces primarily serve functions for specific scenarios, including custom functionalities and performance tuning for target workloads. More importantly, many parameters are tightly integrated with distribution-specific functional modules, which are part of the distribution's features. For example, OpenAnolis 8.8 implements the `update_cpuectlr` runtime parameter interface in the ` / alibaba / prefetch_tuning.c` module to control register updates. This file does not exist in the mainline Linux kernel, reflecting the deep customization of the OpenAnolis 8.8 kernel for a specific platform. Many runtime parameter interfaces are unique to the distribution's kernel, and these distribution-specific runtime parameter interfaces are often less tested; existing fuzzing methods cannot effectively cover these parts. Distribution-specific parameter interfaces often affect critical logic in private code paths or customized modules. Existing fuzzing cannot proactively focus on these distribution-specific code areas, causing many vulnerabilities that only exist in the distribution's kernel to remain untriggered.

[0006] Existing fuzzing tools cannot focus testing resources on release-specific interface-related code.

[0007] Current fuzzing tools often lack an understanding of runtime parameter semantics when generating test cases. Access to these interfaces often depends on a strict system call order, and each parameter has a fixed range of values. For example, / proc / sys / vm / panic_on_oom accepts a value of 0 or 1, while / proc / sys / vm / swappiness accepts a value between 0 and 100. Without understanding these constraints, fuzzing tools often generate invalid or inefficient inputs, thus wasting testing resources and missing deeper kernel vulnerabilities.

[0008] Meanwhile, existing kernel fuzzing tools rely on randomly generated system call sequences, which is inefficient when testing Linux distribution-specific interfaces. For example, the private function `update_cpuectlr_sysctl_handler` in OpenAnolis 8.8 is affected by the value of `sysctl_update_cpuectlr`, which controls register update behavior. The kernel fuzzer's strategy of randomly generating system calls does not proactively generate generic test cases for functions like `update_cpuectlr_sysctl_handler`, resulting in insufficient testing of these distribution-specific kernel code regions. This not only wastes testing resources but also easily misses potential deep vulnerabilities.

[0009] While existing fuzzing techniques are relatively mature for mainline kernels, they suffer from insufficient coverage, low testing efficiency, and limited vulnerability discovery capabilities when dealing with distribution kernels. Therefore, there is an urgent need for a new fuzzing method that can target the runtime parameter interfaces unique to distributions, guide the fuzzer to focus testing resources on the code paths unique to the distribution kernel, and thus more effectively discover hidden vulnerabilities and improve the overall security of the distribution kernel.

[0010] While existing kernel fuzzing tools have achieved significant results in the mainline Linux kernel, they have obvious shortcomings when targeting Linux distribution kernels. To meet different business and performance requirements, distribution kernels often introduce numerous unique runtime parameter interfaces. These interfaces directly affect the kernel execution path and are deeply bound to distribution-specific modules, significantly expanding the attack surface of potential vulnerabilities. However, existing fuzzers cannot automatically identify and effectively utilize these interfaces during testing, resulting in low effectiveness of fuzzing distribution kernels. Summary of the Invention

[0011] This application provides a kernel fuzzing method and related equipment guided by feature interfaces, which can solve the problem of low effectiveness of fuzzing tests on distribution kernels.

[0012] In a first aspect, embodiments of this application provide a kernel fuzzing method guided by a feature interface, the kernel fuzzing method comprising: Based on the target distribution kernel and the corresponding mainline kernel, obtain the unique runtime interface information of the target distribution kernel; Using a large language model, interface test cases for the target distribution kernel are generated based on unique runtime interface information; Obtain multiple general test cases, and determine the priority value of each general test case based on the interface test cases; Fuzz testing of the target distribution kernel is performed using the priority values ​​of all common test cases to obtain the fuzz test results of the target distribution kernel.

[0013] Optionally, based on the target distribution's kernel and its corresponding mainline kernel, obtain the target distribution's unique runtime interface information, including: Run the target distribution kernel and obtain the target distribution kernel's runtime interface information; the target distribution kernel's runtime interface information describes the multiple interfaces triggered when the target distribution kernel runs. Run the mainline kernel and obtain its runtime interface information; the runtime interface information of the mainline kernel is used to describe the multiple interfaces triggered when the mainline kernel runs. By comparing the runtime interface information of the target distribution kernel with that of the mainline kernel, the interfaces that are different from the interfaces triggered by the mainline kernel during runtime are identified as unique runtime interfaces. Use the interface information of the unique runtime interface as the unique runtime interface information of the target distribution kernel.

[0014] Optionally, using a large language model, interface test cases for the target distribution kernel are generated based on specific runtime interface information, including: Define pseudo-system call templates and interface scope generation rules; Using a large language model, the parameter range of the target distribution kernel's unique runtime interface is generated based on interface range generation rules and runtime interface information; Based on parameter ranges and pseudo system call templates, generate interface test cases for the target distribution kernel.

[0015] Optionally, the priority value of each general test case is determined based on the interface test cases, including: Execute the interface test cases on the target distribution kernel to obtain the covered function nodes of the interface test cases; For each general test case, execute the general test case on the target distribution kernel to obtain the covered function nodes of the general test cases; Based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases, determine the priority value of each general test case.

[0016] Optionally, based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases, determine the priority value of each general test case, including: For each general test case, calculate the average distance between the covered function nodes of the general test case and the covered function nodes of the interface test cases; The priority value for each common test case is determined based on all average distances.

[0017] Optionally, the priority value for each common test case is determined based on all average distances, including: Arrange all average distances in descending order, and based on the sorting results, assign a priority value to each general test case according to the strategy that the priority value is inversely proportional to the average distance.

[0018] Secondly, embodiments of this application provide a kernel fuzzing apparatus guided by a feature interface, comprising: The acquisition module is used to obtain the unique runtime interface information of the target distribution kernel based on the target distribution kernel and the mainline kernel corresponding to the target distribution kernel. The generation module is used to generate interface test cases for the target distribution kernel based on the specific runtime interface information using a large language model. The determination module is used to obtain multiple general test cases and determine the priority value of each general test case based on the interface test cases; The fuzzing module is used to perform fuzzing tests on the target distribution kernel using the priority values ​​of all common test cases, and obtain the fuzzing results of the target distribution kernel.

[0019] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned feature interface-guided kernel fuzzing method.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned feature interface-guided kernel fuzzing method.

[0021] The above-mentioned solution in this application has the following beneficial effects: In the embodiments of this application, the unique runtime interface information of the target distribution kernel is obtained based on the target distribution kernel and its corresponding mainline kernel. Then, using a large language model, interface test cases for the target distribution kernel are generated based on the unique runtime interface information. Multiple general test cases are then obtained, and the priority value of each general test case is determined based on the interface test cases. Finally, fuzz testing is performed on the target distribution kernel using the priority values ​​of all general test cases to obtain the fuzz test results. Specifically, identifying the unique runtime interface information of the target distribution kernel and generating interface test cases based on this information allows for analysis of the unique runtime interfaces of the target distribution kernel. This effectively utilizes the unique runtime interface information to explore the unique code regions of the distribution kernel. Determining the priority of general test cases based on the interface test cases and performing fuzz testing on the target distribution kernel based on these priorities improves the depth of vulnerability discovery and the breadth of unique code discovery in the target distribution kernel, thereby enhancing the effectiveness of fuzz testing.

[0022] Other beneficial effects of this application will be described in detail in the following detailed description section. Attached Figure Description

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

[0024] Figure 1 A flowchart of a kernel fuzzing method guided by a feature interface provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the process of generating interface test cases according to an embodiment of this application; Figure 3 A schematic diagram of the structure of a kernel fuzzing device guided by a feature interface provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0025] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0026] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0027] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0031] To address the low effectiveness of existing fuzzing methods for distribution kernels, this application provides a kernel fuzzing method guided by feature interfaces. This method obtains the unique runtime interface information of the target distribution kernel based on the target kernel and its corresponding mainline kernel. Then, using a large language model, it generates interface test cases for the target distribution kernel based on this unique runtime interface information. Next, it obtains multiple general test cases, determines the priority value of each general test case based on the interface test cases, and finally uses the priority values ​​of all general test cases to perform fuzzing on the target distribution kernel, obtaining the fuzzing results. Specifically, identifying the unique runtime interface information of the target distribution kernel and generating interface test cases based on this information allows for analysis of the unique runtime interfaces of the target distribution kernel. This effectively utilizes the unique runtime interface information to explore the unique code regions of the distribution kernel. Determining the priority of general test cases based on the interface test cases and performing fuzzing on the target distribution kernel based on these priorities improves the depth of vulnerability discovery and the breadth of unique code discovery in the target distribution kernel, thereby enhancing the effectiveness of fuzzing.

[0032] The kernel fuzzing method guided by the feature interface provided in this application will be illustrated by example below.

[0033] like Figure 1 As shown, the kernel fuzzing method guided by the feature interface provided in this application includes the following steps: Step 11: Based on the target distribution kernel and the corresponding mainline kernel, obtain the unique runtime interface information of the target distribution kernel.

[0034] The target distribution kernels mentioned above are those that require fuzz testing. These distribution kernels are versions of the mainline kernel (the original kernel maintained by the Linux kernel development team) that have been modified by the developer. The unique runtime interface information described above describes the unique runtime interfaces triggered by the target distribution kernel during runtime, including information such as the ID of the unique runtime interface.

[0035] In some embodiments of this application, the step of obtaining the unique runtime interface information of the target distribution kernel based on the target distribution kernel and the mainline kernel corresponding to the target distribution kernel includes: The first step is to run the target distribution's kernel and obtain the target distribution's kernel's runtime interface information.

[0036] The aforementioned target distribution kernel runtime interface information describes multiple interfaces triggered during the runtime of the target distribution kernel, including interface IDs and other information.

[0037] For example, the target distribution kernel can be run on a virtual machine with vendor-specific configuration (such as anolis_defconfig used by OpenAnolis). A Python script can be used to perform a full scan of the kernel's / sys and / proc / sys directories, collect multiple interfaces triggered at runtime, and integrate the IDs and other information of these interfaces into runtime interface information.

[0038] It should be noted that after obtaining the interfaces triggered at runtime, the collected interfaces are strictly filtered to remove non-writable interfaces—these interfaces cannot trigger kernel logic through write operations and are of no practical significance for fuzz testing. String-type interfaces are also excluded—since these interfaces usually lack official documentation support, it is difficult to automatically generate effective test cases. Finally, only writable int-type interfaces are retained, as these interfaces have clear numerical operation attributes and are more suitable for subsequent automated testing.

[0039] The second step is to run the mainline kernel and obtain the mainline kernel's runtime interface information.

[0040] The mainline kernel's runtime interface information describes the multiple interfaces triggered during mainline kernel runtime, including interface IDs and other information.

[0041] For example, the mainline kernel can be run on a virtual machine using the default defconfig configuration, and a Python script can be used to perform a full scan of the kernel's / sys and / proc / sys directories to collect runtime interface information.

[0042] The third step is to compare the runtime interface information of the target distribution kernel with that of the mainline kernel, and identify the interfaces that are different from those triggered by the mainline kernel during runtime as unique runtime interfaces.

[0043] Specifically, the interfaces in the target distribution kernel's runtime interface information and the mainline kernel's runtime interface information are compared one by one, and only the interfaces that "exist in the distribution kernel but not in the mainline kernel" are retained as unique runtime interfaces.

[0044] The fourth step is to use the interface information of the unique runtime interface as the unique runtime interface information of the target distribution kernel.

[0045] For example, the ID, identifier, parameter range, and other interface information of the running interface can be used as unique running interface information.

[0046] Step 12: Using the large language model, generate interface test cases for the target distribution kernel based on the unique runtime interface information.

[0047] The above interface test cases are fuzz test cases that cover the unique runtime interfaces of the target distribution's kernel.

[0048] In some embodiments of this application, the steps described above for generating interface test cases for the target distribution kernel based on specific runtime interface information using a large language model include: The first step is to define the pseudo system call template and interface scope generation rules.

[0049] The aforementioned pseudo-system call template is used to define system call sequences. Encapsulating necessary system call sequences (such as "open-write-close") within a custom function ensures the correct order of operations when accessing each runtime parameter interface, avoiding test failures caused by random system call sequences. This is a pre-defined call template.

[0050] The aforementioned interface range generation rules include: for interfaces with clearly defined parameter ranges, the range is generated directly; for interfaces with broad ranges, a maximum upper limit is set; and for interfaces without defined ranges, a fixed value is generated. Through this method, the large language model can automatically generate correct parameter range constraints for most interfaces.

[0051] The second step involves using a large language model to generate the parameter range of the target distribution kernel's unique runtime interface based on interface range generation rules and runtime interface information.

[0052] Specifically, the interface range generation rules and runtime interface information are input into the large language model, and by setting preset prompt words for the large language model, the model is guided to generate the parameter range of the unique runtime interface.

[0053] For example, the LLM is first provided with an interface path for distribution-specific runtime parameters, and the initial range information (x, y) is obtained. Next, the RPG uses this interface path to check its tuning database and look for a matching interface record. If found, the RPG extracts the range information (a, b) from the database; if not found, the RPG assigns the LLM's range (x, y) to (a, b).

[0054] The third step is to generate interface test cases for the target distribution kernel based on the parameter range and the pseudo system call template.

[0055] For example, a large language model can be used to generate interface test cases for the target distribution kernel based on parameter ranges and pseudo-system call templates. In these interface test cases, four behavioral strategies are designed for each interface: boundary value testing: testing the minimum and maximum parameter values ​​to check system performance under extreme conditions; out-of-range testing: writing values ​​outside the valid range to check the system's error handling capabilities; random write: writing random values ​​within the valid range to trigger different code paths; and common value write: writing parameter values ​​from a tuning database to test the stability of commonly used parameters.

[0056] For example, the process of generating interface test cases is as follows: Figure 2 As shown in the figure, the code in the parameter interfaces section is the interface parameter, LLM-Analysis is the large language model analysis section, tuning database is the parameter tuning section, pseudo syscall template is the pseudo system call template, and the pseudo syscall section is the code example of the pseudo system call template.

[0057] Step 13: Obtain multiple general test cases and determine the priority value of each general test case based on the interface test cases.

[0058] The above general test cases are test cases that can perform fuzz testing on the target distribution kernel and the mainline kernel.

[0059] In some embodiments of this application, general test cases can be obtained by accessing publicly available test case libraries, generating large language models, etc. The steps for determining the priority value of each general test case based on interface test cases include: The first step is to execute the interface test cases on the target distribution kernel to obtain the covered function nodes of the interface test cases.

[0060] Specifically, after executing the interface test cases, all function nodes called in the target distribution kernel will be used as the covering function nodes of the interface test cases.

[0061] The second step is to execute the common test cases on the target distribution kernel for each common test case, thereby obtaining the covered function nodes of the common test cases.

[0062] Specifically, after executing the general test cases, all function nodes called in the target distribution kernel will be used as the covered function nodes of the general test cases.

[0063] The third step is to determine the priority value of each general test case based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases.

[0064] Specifically, for each general test case, the average distance between the coverage function nodes of the general test case and the coverage function nodes of the interface test cases is calculated; the priority value of each general test case is determined based on all average distances.

[0065] For example, the step of determining the priority value of each general test case based on all average distances includes: arranging all average distances in descending order, and according to the ranking result, assigning a priority value to each general test case based on a strategy that the priority value is inversely proportional to the average distance, as expressed by: ; in, This is the priority value. The average distance, This is the arctangent function. This formula guarantees that the priority value is between 0 and 1, and that the priority is inversely proportional to the distance—the shorter the distance, the higher the priority of the test case.

[0066] It should be noted that the distance between corresponding covered function nodes can be calculated using the function control flow graph, and the average distance can be obtained by averaging these distances. In the function control flow graph, nodes represent kernel functions, and edges represent the call relationships between functions. Shorter paths indicate stronger functional coupling (e.g., shared subsystems), while longer paths indicate weaker interaction (e.g., cross-module calls).

[0067] For example, nodes covered by release-specific interface test cases are stored as a comparison node group. This group is continuously updated as release-specific interface test cases are executed. For nodes covered by general test cases, the shortest distance between their node set and the comparison node group is calculated. Using a priority formula, this distance determines the generation priority of the corresponding test case. The shorter the distance, the closer the test case is to the release-specific interface related code. The specific algorithm code (Algorithm 1) is as follows: Input: Test case t, Test case cover node group NG, Contrast nodegroup CNG, configurable value ; Output: Updated CNG, Priority value p; 1.if t is distribution-specific interface test case then; 2. for each node do; 3.if then; 4. ; 5. / / Add new function to contrast group; 6. ; / / Set priority value to ; 7.else; 8. ; / / Initialize empty list for distances; 9.for each node do; 10. ; 11. / / Shortest distance algorithm; 12. ; / / Append the distance; 13. ; / / Calculate average distance; 14. ; / / Calculate priority value; 15.return ; 16. / / Return updated contrast node group and priority value。

[0068] Algorithm 1 details the core concepts of the interface-guided release fuzzing loop. The input to Algorithm 1 includes the test case t, the test case coverage node group NG, the comparison node group (CNG), and a configurable value pb. The output is the updated comparison node group CNG and the priority value p. First, Algorithm 1 checks if the test case is a distribution-specific interface test case (line 1). If so, Algorithm 1 iterates through each node fn covered by the test case that belongs to NG and checks if that node is already in the comparison node group CNG. If the node is not in CNG, it is added to the comparison node group (lines 2-5). The priority value of the interface test case is set to a fixed value (p=pb(line 6)), which is configurable. If the test case is not a distribution-specific interface test case, Algorithm 1 first initializes an empty distance list distances (line 8). Then, it iterates through each node fn∈NG and uses Algorithm 2 to calculate the shortest distance d from each node to each node in the comparison node group (line 10). After the calculation is complete, all distance values ​​are added to the distance list `distances` (line 12), and the average distance `de` is calculated from this distance list (line 13). Finally, the priority value `p` is calculated using Formula 1 (line 14). Algorithm 1 returns the updated comparison node group `CNG` and the calculated priority value `p` (lines 15-16).

[0069] The specific code for Algorithm 2 is as follows: Input: Node Contrast node group CNG; Output: Shortest distance d; 1. ; ; 2.while queue is not empty do; 3. ; 4.if then; 5. ; / / Distance exceeds limit return d; 6. Else; 7.if then; 8. / / Found CNG node; 9. return d; 10.for each neighbor neb of current do; 11.if and then; 12. ; 13. ; 14. return d.

[0070] Algorithm 2 calculates the shortest functional distance from a given kernel node fn to the nearest node in the comparison node group CNG. Algorithm 2 first initializes a queue with the starting node fn and a distance of 0, marking fn as visited (line 1). Then, it enters a loop, retrieving the head node current and its associated distance cur_dist from the queue. If current is found in the comparison node group CNG, it immediately returns cur_dist as the shortest distance (lines 7-9). If not found, the algorithm processes all unvisited neighbors of current, adding each neighbor to the visited set and adding them to the queue along with the incremented distance value (cur_dist + 1) (lines 10-13). Algorithm 2's search continues until a node is found in CNG, or cur_dist exceeds the maximum value d_max (lines 4-5).

[0071] Step 14: Perform fuzz testing on the target distribution kernel using the priority values ​​of all common test cases to obtain the fuzz test results of the target distribution kernel.

[0072] The fuzz test results mentioned above include basic runtime information and existing fault information when the target distribution kernel runs common test cases.

[0073] For example, test cases can be selected from all general test cases based on priority values. These selected test cases can then be used to perform fuzz testing on the target distribution's kernel to obtain the fuzzing results. In other words, the probability of a general test case being selected can be set based on its priority value; the higher the priority value, the higher the probability. General test cases with higher priority values ​​are optimized first, which helps to discover deeper vulnerabilities in distribution-specific interface code. Alternatively, priority values ​​can be used as weights to generate new general test cases based on the current general test cases. These test cases are more likely to cover functions closer to the target interface.

[0074] It is worth mentioning that after identifying the unique runtime interface information of the target distribution's kernel, interface test cases are generated based on this information. This allows for analysis of the unique runtime interfaces of the target distribution's kernel, effectively utilizing the unique runtime interface information to explore the unique code regions of the distribution's kernel. The priority of general test cases is determined based on the interface test cases, and fuzzing is performed on the target distribution's kernel based on the priority. This improves the depth of vulnerability discovery and the breadth of unique code discovery in the target distribution's kernel, thereby enhancing the effectiveness of fuzzing.

[0075] Furthermore, the method of this application has the following beneficial effects: This invention enables the automated generation of release-specific runtime parameter interface test cases that conform to semantic constraints. Existing fuzzing tools, when faced with runtime parameter interfaces added to the kernel of a release, often rely on random values ​​or fixed templates for parameter input. Due to a lack of understanding of the interface's value range and access order, invalid or inefficient inputs are easily generated. This application, by combining pseudo-system call templates, large-scale model analysis, and a software database for tuning during the test case generation phase, not only ensures the correctness of the interface access order but also automatically infers and corrects the legal value range for each interface and supplements it with commonly used parameter configurations in real production environments. The resulting test inputs cover scenarios such as legal intervals, boundary values, and out-of-bounds values, and can simulate frequently used configurations in actual systems, thereby reducing the proportion of invalid test inputs, improving fuzzing efficiency, and significantly increasing the chance of triggering deep logic vulnerabilities. Experimental results show that the number of unknown vulnerabilities triggered by this method is on average 32% higher than that of schemes that do not use parameter range modeling, verifying its effectiveness in actual vulnerability discovery.

[0076] This application enables the concentration of testing resources on distribution-specific code paths, improving coverage and vulnerability discovery rates. Traditional fuzzing tools rely on randomly generated system call sequences, often focusing on common kernel paths and failing to cover distribution-specific private modules and new features. This application achieves dynamic allocation of testing resources by extracting differentiated runtime parameter interfaces between the distribution kernel and the mainline kernel, and introducing a function control flow graph-based guidance mechanism during execution. Specifically, after executing distribution-specific interface test cases, the function nodes they cover are continuously added to the control group; for general test cases, the shortest path distance between their covered functions and the control group is calculated, and the expansion order of test cases is dynamically adjusted using a priority formula. In this way, fuzzing can gradually approach and cover more deep logic regions related to distribution-specific interfaces. According to experimental data, this solution improves the average branch coverage by 20.4% compared to Syzkaller and 21.2% compared to Healer on four kernel distributions: Ubuntu 22.04, Fedora 42, OpenAnolis 8.8, and OpenAnolis 23.1, significantly improving the problem of insufficient coverage.

[0077] This application aims to discover more unknown vulnerabilities in real-world distribution environments, thereby enhancing the depth of vulnerability discovery. Existing fuzzing methods are limited in their ability to effectively explore distribution-specific code regions. This application, through a combination of interface extraction, range modeling, and bootstrapping mechanisms, can trigger deep errors in distribution-specific modules. For example, in the io_uring module of the OpenAnolis kernel, this application discovered a global out-of-bounds read vulnerability caused by the extended opcode not updating boundary checks. This vulnerability exists only in distributions and cannot be triggered in the mainline kernel. Overall, this application discovered 22 previously unknown vulnerabilities in the kernels of four distributions: Ubuntu 22.04, Fedora 42, OpenAnolis 8.8, and OpenAnolis 23.1. Of these, 13 are distribution-specific, 15 have been confirmed by the community, and 10 have been patched. Compared to existing technologies, this solution effectively fills the blind spots in distribution vulnerability detection, demonstrating outstanding performance in improving the quantity and depth of vulnerability discovery.

[0078] The following is an exemplary description of the fuzzing apparatus for the distribution kernel provided in this application.

[0079] like Figure 3 As shown, this application embodiment provides a kernel fuzzing device guided by a feature interface. The feature interface-guided kernel fuzzing device 300 includes: The acquisition module 301 is used to acquire the unique runtime interface information of the target distribution kernel based on the target distribution kernel and the mainline kernel corresponding to the target distribution kernel. The generation module 302 is used to generate interface test cases for the target distribution kernel based on the specific runtime interface information using a large language model. Module 303 is used to obtain multiple general test cases and determine the priority value of each general test case based on the interface test cases; The fuzzing module 304 is used to perform fuzzing on the target distribution kernel using the priority values ​​of all common test cases, and obtain the fuzzing results of the target distribution kernel.

[0080] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0082] like Figure 4 As shown, an embodiment of this application provides a terminal device, wherein the terminal device D10 of this embodiment includes: at least one processor D100 ( Figure 4 The diagram shows only one processor, a memory D101, and a computer program D102 stored in the memory D101 and executable on the at least one processor D100, wherein the processor D100 executes the computer program D102 to implement the steps in any of the above method embodiments.

[0083] Specifically, when the processor D100 executes the computer program D102, it obtains the unique runtime interface information of the target distribution kernel based on the target distribution kernel and its corresponding mainline kernel. Then, using a large language model, it generates interface test cases for the target distribution kernel based on the unique runtime interface information. Next, it obtains multiple general test cases, determines the priority value of each general test case based on the interface test cases, and finally performs fuzz testing on the target distribution kernel using the priority values ​​of all general test cases to obtain the fuzz test results for the target distribution kernel. In this process, identifying the unique runtime interface information of the target distribution kernel and generating interface test cases based on this information allows for analysis of the unique runtime interfaces of the target distribution kernel. This effectively utilizes the unique runtime interface information to explore the unique code regions of the distribution kernel. Determining the priority of general test cases based on the interface test cases and performing fuzz testing on the target distribution kernel based on these priorities improves the depth of vulnerability discovery and the breadth of unique code discovery in the target distribution kernel, thereby enhancing the effectiveness of fuzz testing.

[0084] The processor D100 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0085] In some embodiments, the memory D101 may be an internal storage unit of the terminal device D10, such as a hard disk or memory of the terminal device D10. In other embodiments, the memory D101 may be an external storage device of the terminal device D10, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the terminal device D10. Furthermore, the memory D101 may include both internal and external storage units of the terminal device D10. The memory D101 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory D101 can also be used to temporarily store data that has been output or will be output.

[0086] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0087] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

[0088] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a feature interface-guided kernel fuzzing method apparatus / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0089] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0090] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention.

Claims

1. A kernel fuzzing method guided by a feature interface, characterized in that, include: Based on the target distribution kernel and the mainline kernel corresponding to the target distribution kernel, obtain the unique runtime interface information of the target distribution kernel; Using a large language model, interface test cases for the target distribution kernel are generated based on the unique runtime interface information; Obtain multiple general test cases, and determine the priority value of each general test case based on the interface test cases; The target distribution kernel is fuzzed using the priority values ​​of all common test cases to obtain the fuzz test results of the target distribution kernel. The step of generating interface test cases for the target distribution kernel based on the specific runtime interface information using a large language model includes: Define pseudo-system call templates and interface scope generation rules; Using a large language model, the parameter range of the target distribution kernel's unique runtime interface is generated based on the interface range generation rules and the runtime interface information; Based on the parameter range and the pseudo system call template, generate interface test cases for the target distribution kernel; The process of determining the priority value of each of the general test cases based on the interface test cases includes: Execute the interface test cases on the target distribution kernel to obtain the covered function nodes of the interface test cases; For each of the general test cases, execute the general test cases on the target distribution kernel to obtain the covered function nodes of the general test cases; Based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases, the priority value of each general test case is determined.

2. The kernel fuzzing method according to claim 1, characterized in that, The step of obtaining the unique runtime interface information of the target distribution kernel based on the target distribution kernel and the corresponding mainline kernel includes: Run the target distribution kernel and obtain the target distribution kernel's runtime interface information; the target distribution kernel's runtime interface information describes multiple interfaces triggered during the runtime of the target distribution kernel; Run the mainline kernel and obtain the mainline kernel's runtime interface information; the mainline kernel's runtime interface information is used to describe multiple interfaces triggered when the mainline kernel runs; By comparing the runtime interface information of the target distribution kernel with the runtime interface information of the mainline kernel, the interfaces that are different from the interfaces triggered by the mainline kernel during runtime are identified as unique runtime interfaces. The interface information of the unique runtime interface is used as the unique runtime interface information of the target distribution kernel.

3. The kernel fuzzing method according to claim 1, characterized in that, The priority value of each general test case is determined based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases, including: For each of the general test cases, calculate the average distance between the coverage function nodes of the general test cases and the coverage function nodes of the interface test cases; The priority value for each of the general test cases is determined based on all average distances.

4. The kernel fuzzing method according to claim 3, characterized in that, The process of determining the priority value for each of the general test cases based on all average distances includes: Arrange all average distances in descending order, and based on the sorting results, assign a priority value to each general test case according to the strategy that the priority value is inversely proportional to the average distance.

5. A kernel fuzzing device guided by a feature interface, characterized in that, include: The acquisition module is used to acquire the unique runtime interface information of the target distribution kernel based on the target distribution kernel and the mainline kernel corresponding to the target distribution kernel. The generation module is used to generate interface test cases for the target distribution kernel based on the specific runtime interface information using a large language model. The determination module is used to obtain multiple general test cases and determine the priority value of each general test case based on the interface test cases; The fuzzing module is used to perform fuzzing tests on the target distribution kernel using the priority values ​​of all common test cases, and to obtain the fuzzing test results of the target distribution kernel. Specifically, the generation module is used to implement: Define pseudo-system call templates and interface scope generation rules; Using a large language model, the parameter range of the target distribution kernel's unique runtime interface is generated based on the interface range generation rules and the runtime interface information; Based on the parameter range and the pseudo system call template, generate interface test cases for the target distribution kernel; The determining module is specifically used to implement: Execute the interface test cases on the target distribution kernel to obtain the covered function nodes of the interface test cases; For each of the general test cases, execute the general test cases on the target distribution kernel to obtain the covered function nodes of the general test cases; Based on the coverage function nodes of the interface test cases and the coverage function nodes of all general test cases, the priority value of each general test case is determined.

6. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the kernel fuzzing method guided by the feature interface as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the kernel fuzzing method guided by the feature interface as described in any one of claims 1 to 4.

Images