A vulnerability fixing method, system and program product of a Linux system

Abstract

The application discloses a vulnerability repair method, system and program product of a Linux system, and the method comprises the following steps: generating a plurality of candidate repair patches for repairing a target component based on a basic repair patch of the target component and feature data matched with the target component; for each candidate repair patch, obtaining a quantitative evaluation value of the candidate repair patch, and determining the candidate repair patch with the highest quantitative evaluation value as a target repair patch; performing a compilation test on the target repair patch, and obtaining an actual repair patch of the target component based on the compilation test result. The embodiment of the application generates a repair patch based on all data (i.e., corresponding feature data) of the target component from a low version to a high version, so that the generated repair patch has evolution data support, thereby guaranteeing the stability of subsequent repair; in addition, the target repair patch is subjected to a compilation test in advance, thereby improving the vulnerability repair efficiency and repair accuracy.

Description

Technical Field

[0001] This application relates to the field of vulnerability remediation, specifically to a vulnerability remediation method, system, and program product for a Linux system. Background Technology

[0002] With the rapid development of information systems, the security and vulnerability protection of Linux systems have become a core concern. In recent years, the number of security vulnerabilities disclosed by the Common Vulnerabilities and Exposures (CVE) system has continued to increase, leading to a rapid growth in the demand for software remediation.

[0003] In practical applications, the versions of Linux system components (including but not limited to the Linux system kernel, system libraries, service processes, user-space tools, etc.) used by enterprises or users are usually lower than the latest official version. However, most official patches are only applicable to the latest or higher versions. This means that official patches cannot be directly applied to the version currently used by users, and patch modification and adaptation must be performed in actual applications.

[0004] However, such cross-version repair processes are highly dependent on human operation, and are labor-intensive and time-consuming, which can easily lead to repair errors, thereby reducing the efficiency and accuracy of vulnerability repair. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a vulnerability repair method, system and program product for Linux system. This method generates repair patches based on all data (i.e. corresponding feature data) of the target component from low version to high version, so that the generated repair patches have evolution data support and ensure the stability of the repair. Secondly, the identified target repair patches are pre-compiled and tested to avoid compatibility and security issues that may exist in the subsequent repair process, thereby improving the efficiency and accuracy of vulnerability repair.

[0006] In a first aspect, the present invention provides a method for patching vulnerabilities in a Linux system, wherein the vulnerabilities affect the normal operation of target components in the Linux system, the method comprising: Based on the base patch for the target component and the feature data that matches the target component, multiple candidate patches for fixing the target component are generated. The feature data is data from a feature vector database that matches the target component. The feature data is used to characterize at least all code change records and corresponding source code of the target component during version iteration. For each candidate patch, a quantitative evaluation value is obtained, and the candidate patch with the highest quantitative evaluation value is determined as the target patch; the quantitative evaluation value is related to the repair effect of the candidate patch on the target component; The target patch is compiled and tested, and the actual patch for the target component is obtained based on the compilation and test results.

[0007] In one possible implementation, the process of constructing the feature vector database corresponding to each target component includes: Obtain the baseline version source code, the high version source code, and all code change records between the baseline version source code and the high version source code of the target component, and parse the baseline version source code, the high version source code, and all code change records; Based on the parsing results, a corresponding abstract syntax tree structure is generated, and multiple feature index files are obtained based on the static features represented by the abstract syntax tree structure. Each feature index file is semantically vectorized to construct a feature vector database based on the obtained feature data.

[0008] In one possible implementation, each feature index file includes at least the function name, the file path, the version or commit identifier, the corresponding abstract syntax tree structure feature, the function call relationship, and the historical change record.

[0009] In one possible implementation, based on the base patch for the target component and feature data matching the target component, multiple candidate patches for repairing the target component are generated, including: Based on the basic repair patch and feature data, a retrieval statement is formed. The retrieval statement is then used as the input context to input the large language model, which infers and generates multiple candidate repair patches.

[0010] In one possible implementation, the target fix patch is compiled and tested, including: The target patch is applied to the baseline version of the target component's source code for compilation and testing to obtain the compilation results of the target patch and the running status of the target component.

[0011] In one possible implementation, the actual patch for the target component is obtained based on the results of compilation tests, including: If the compilation test results indicate that the target patch was compiled successfully and the target component is running normally, then the actual patch for the target component is determined to be the target patch.

[0012] In one possible implementation, the actual patch for the target component is obtained based on the results of compilation tests, including: If the compilation test results indicate that the target patch failed to compile and / or the target component's running state is abnormal, extract the error characteristics of the target patch; Error characteristics and target fix patches are input into a large language model for iterative adjustment until the compilation test results of the adjusted target fix patch indicate that the target fix patch is successfully compiled and the target component is running normally. The iteratively adjusted target fix patch is then identified as the actual fix patch for the target component.

[0013] In one possible implementation, the method further includes: If the number of iterations exceeds the preset number, the target fix patch after the previous iteration will be determined as the actual fix patch for the target component.

[0014] Secondly, a vulnerability remediation system for a Linux system is provided. The vulnerability in this Linux system affects the normal operation of target components within the system. This system includes: The generation module is used to generate multiple candidate patching methods for fixing the target component based on the base patching method for the target component and the feature data matching the target component. The feature data is data from a feature vector database that matches the target component. The feature data is used to characterize at least all code change records and corresponding source code during the version iteration process of the target component. The first processing module is used to obtain the quantitative evaluation value of each candidate repair patch, and determine the candidate repair patch with the highest quantitative evaluation value as the target repair patch; the quantitative evaluation value is related to the repair effect of the candidate repair patch on the target component; The second processing module is used to compile and test the target patch, and repair the target component based on the compilation and test results.

[0015] Thirdly, a computer program product is provided, which includes instructions that, when executed, perform the method described in any one of the first aspects.

[0016] Fourthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in any one of the first aspects above.

[0017] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in any one of the first aspects above.

[0018] Compared to existing vulnerability remediation methods that heavily rely on human intervention and are prone to errors, the vulnerability remediation method, system, and program products for Linux systems provided in this application generate remediation patches based on all data (i.e., corresponding feature data) of the target component as it evolves from a lower version to a higher version. This ensures that the generated remediation patches have evolution data support (i.e., context support), avoiding problems such as interface mismatch, semantic offset, or structural conflict, and guaranteeing the stability of the remediation. Secondly, the determined target remediation patches are pre-compiled and tested, avoiding compatibility and security issues that may occur during subsequent remediation, thereby improving the efficiency and accuracy of vulnerability remediation. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a method for patching vulnerabilities in a Linux system provided in an embodiment of this application. Figure 2 This is another flowchart illustrating the vulnerability repair method for the Linux system provided in this application embodiment; Figure 3 This is a block diagram of a vulnerability repair system 300 for a Linux system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0022] In existing technologies, official patches for security vulnerabilities in Linux systems are typically released based on higher version components, while older versions lack continuous maintenance. However, the Linux system components used by enterprises or users are generally lower than the latest official versions. This results in higher version patches lacking necessary contextual support in older environments, easily leading to problems such as interface incompatibility, semantic deviations, or structural conflicts. Ultimately, this results in poor patch stability, low efficiency, and the potential introduction of new bugs.

[0023] Therefore, the low efficiency and accuracy of vulnerability patching in Linux systems has become an urgent problem to be solved.

[0024] In response, this application provides a method for patching vulnerabilities in Linux systems. This method can generate patching patches based on the sequential chain of patches submitted multiple times between low and high versions of a component, as well as the patch dependencies during function evolution. This avoids conflicts or mismatches that occur when only the vulnerable parts of the source code of the current version component are analyzed individually, thus ensuring the stability of vulnerability patching.

[0025] In one possible implementation, Figure 1 This is a flowchart illustrating a vulnerability remediation method for a Linux system provided in an embodiment of this application, such as... Figure 1 As shown, the method specifically includes the following steps: Step S101: Based on the basic repair patch of the target component and the feature data matching the target component, generate multiple candidate repair patches for repairing the target component.

[0026] Among them, the basic fix patch for the target component can be the official fix patch for the target component; the feature data matching the target component can be data from a feature vector database that matches the target component. This feature data is used to characterize at least all code change records and corresponding source code of the target component during the version iteration process.

[0027] In one possible implementation, one can first determine whether a feature vector database matching the target component is stored locally based on the baseline identifier of the target component.

[0028] For example, the existence of a local vector directory corresponding to the baseline can be determined based on the baseline identifier of the target component. If the directory exists, it means that a feature vector database matching the target component is stored locally; otherwise, it means that a feature vector database matching the target component is not stored locally.

[0029] For example, if a feature vector database matching the target component is stored locally, then the feature data matching the target component is obtained from the feature vector database; otherwise, a feature vector database matching the target component is constructed.

[0030] Correspondingly, a feature vector database matching the target component can be constructed based on the baseline version source code, the high version source code, and all code change records between the baseline version source code and the high version source code (i.e., all code change records and corresponding source code of the target component during the version iteration process); where the baseline version is the target low version of the target component.

[0031] In one possible implementation, a retrieval statement can be formed based on the basic repair patch and feature data. This retrieval statement is then used as the input context to input the Large Language Model (LLM) and drive the LLM to infer and generate multiple candidate repair patches.

[0032] In this embodiment, the combination of the official patch and feature data is used as the retrieval input for Retrieval-Augmented Generation (RAG), and the input context of LLM is constructed based on this to analyze the relationship between all historical commits and vulnerabilities between the two version differences, thereby tracing back the preceding patches required by the official patch, and finally generating a patch suitable for the lower version of the component, thus realizing cross-version adaptive patch generation.

[0033] Step S102: For each candidate repair patch, obtain the quantitative evaluation value of the candidate repair patch, and determine the candidate repair patch with the highest quantitative evaluation value as the target repair patch.

[0034] The quantitative evaluation value is related to the repair effect of the candidate repair patch on the target component.

[0035] In one possible implementation, the effectiveness of the target component repair can be determined based on four dimensions of parameters: repair effectiveness, logical compliance, engineering standardization, and evidence reliability.

[0036] For example, the quantitative evaluation value of a candidate repair patch can be the confidence value corresponding to the candidate repair patch.

[0037] Correspondingly, remediation effectiveness is used to quantitatively evaluate the depth of coverage of the root cause of the vulnerability by the candidate patch and the ease of bypassing it; logical compliance is used to determine the regression risk and security issues after the candidate patch is ported by comparing it with the original semantic logic; engineering standardization is used to evaluate the focus and maintainability of code changes; and evidence reliability can be weighted by the authority of the context such as official patch and CVE description to ensure that all evaluation data are based on trusted input.

[0038] In this embodiment, by introducing a confidence assessment mechanism, the security repair decision is modeled. By using a weighted synthesis and evidence multiplier calculation model, the confidence of candidate repair patches can be accurately ranked, and automatic repair is performed only on the repair patch with the highest confidence score. This fundamentally ensures the compatibility and security of cross-version porting, and improves the efficiency of subsequent repairs and the security after repair.

[0039] Step S103: Compile and test the target patch, and obtain the actual patch for the target component based on the compilation and test results.

[0040] In one possible implementation, the target patch can be applied to the baseline version of the target component's source code for compilation and testing to obtain the compilation results of the target patch and the running status of the target component.

[0041] The running status of the target component corresponds to the vulnerability patching status: when the vulnerability is not logically patched, the semantics are inconsistent, and the running status of the target component is abnormal; otherwise, when the vulnerability is logically patched, the semantics are consistent, and the running status of the target component is normal.

[0042] For example, if the compilation test results indicate that the target patch was compiled successfully and the target component is running normally, then the actual patch for the target component is determined to be the target patch.

[0043] For example, if the compilation test results indicate that the target patch failed to compile and / or the target component's running state is abnormal, then the target patch is subjected to closed-loop iterative optimization.

[0044] Specifically, error features of the target patch can be extracted and input into the LLM for iterative adjustment (i.e., multi-round adaptive hint optimization) until the compilation test results of the adjusted target patch indicate that the target patch has been successfully compiled and the target component is running normally (i.e., the target patch meets the semantic consistency requirements). Then, the iteratively adjusted target patch is determined as the actual patch for the target component.

[0045] In one example, the reason for the failure to compile the target patch can be determined based on the extracted error characteristics of the target patch. Based on the reason for the failure, structured constraint information of the target patch can be generated, and then the structured constraint information and the target patch can be input into the LLM.

[0046] In one possible implementation, if the number of iterations of the target repair patch exceeds a preset number, then the target repair patch after the previous iteration is determined as the actual repair patch for the target component.

[0047] That is, if the iterative adjustment of the target fix patch reaches the maximum number of iterations threshold, then the target fix patch after the previous iteration adjustment is used as the actual fix patch for the target component; where the maximum number of iterations threshold is, for example, 5.

[0048] To address the issue that existing cross-version vulnerability remediation technologies utilize various models to assist in generating remediation patches, but a single generated patch often fails to directly compile or fully fix the target vulnerability, this embodiment generates structured constraints for failed or semantically inconsistent remediation patches through compilation and testing. These constraints are then fed back to the LLM (Local Management Model) for multiple rounds of adaptive optimization to generate new remediation patches. This closed-loop iterative optimization avoids a high degree of reliance on manual intervention and improves remediation efficiency.

[0049] In another embodiment of this application, a specific construction process for the feature vector database corresponding to the target component is also provided.

[0050] In one possible implementation, the baseline version source code, the high version source code, and all code change records of the target component can be parsed to generate the corresponding abstract syntax tree structure based on the parsing results. Then, based on the static features represented by the abstract syntax tree structure, multiple feature index files are obtained, and each feature index file is semantically vectorized to construct a feature vector database based on the feature data obtained from the processing.

[0051] Among them, the baseline version source code, the high version source code, and all code change records of the target component can be obtained through a pre-configured acquisition system.

[0052] For example, a high-performance parser generation tool (tree-sitter library) can be used to parse the source code of the two versions and the historically changed code to generate the corresponding abstract syntax tree (i.e., AST) structure based on the parsing results; that is, the AST structure records the corresponding functions, statements, expressions and other structural information.

[0053] For example, a code static feature index can be constructed based on the static features represented by the AST structure, and the code static feature index can be output as multiple feature index files. Among them, static features can include function features, parameter features, operation features, and return features, etc.; the feature index files are structured lightweight data exchange format (JavaScript Object Notation, or JSON for short) files.

[0054] Specifically, the code static feature index is constructed using functions as the basic unit (i.e., the code static feature index can also be called a function-level static index). Each output feature index file includes the function name, the file path, the version or commit identifier (e.g., ID), the corresponding abstract syntax tree structure feature (i.e., AST structure feature), the function call relationship, and the historical change record, etc.

[0055] In one example, each feature index file contains file-level information such as file path, language, size, and line number to identify the basic attributes of the file in the codebase; each feature index file contains function-level features such as function name, start and end line numbers, and static features extracted from the function; among which, the extracted static features include, for example, APIs called, declared local variables, and included control flow structures (e.g., if, for, while).

[0056] For example, semantic vectorization processing can be performed on each of the above feature index files using embedding techniques to construct a feature vector database based on the processed feature data.

[0057] Correspondingly, when retrieving feature data from the feature vector database, the AST structure features of the functions involved are first extracted from the high-version patch and vectorized. Then, similarity matching and structure comparison are performed in the constructed function-level static index to locate semantically similar or related functions and code fragments in the low-version source code, thereby providing a basis for the adaptation and migration of the patch in the low version.

[0058] In this embodiment, by parsing each historical commit from low to high versions of the target component, and combining patch change information with vectorized indexing technology, cross-version semantic alignment between the low-version source code of the target component and the high-version patch is achieved, thereby ensuring the adaptability and semantic consistency of the patch in the low-version environment.

[0059] In another embodiment of this application, another method for patching vulnerabilities in a Linux system is also provided.

[0060] In one possible implementation, Figure 2This is another flowchart illustrating the vulnerability remediation method for a Linux system provided in this application embodiment. The process specifically includes the following steps: Step S201: Enter the name of the target component and the basic repair patch.

[0061] Step S202: Determine whether a feature vector database that matches the target component exists.

[0062] For example, if it exists, then proceed to step S2031; otherwise, proceed to step S2032.

[0063] In step S2031, LLM generates multiple candidate repair patches based on the input context formed by the basic repair patch and feature data.

[0064] Step S2032: Construct a feature vector database that matches the target component.

[0065] Step S204: Obtain the confidence value of each candidate repair patch, and determine the candidate repair patch with the highest confidence value as the target repair patch.

[0066] Step S205: Determine whether the target patch has passed compilation and testing verification.

[0067] For example, if it passes, then proceed to step S2061; otherwise, proceed to step S2062.

[0068] Step S2061: Determine the actual repair patch for the target component as the target repair patch.

[0069] Step S2062: Determine whether the number of loop iterations exceeds the threshold.

[0070] For example, if so, proceed to step S2061; otherwise, proceed to step S207.

[0071] Step S207: Input the error features of the target repair patch and the target repair patch into the large language model to iteratively adjust the target repair patch.

[0072] In this embodiment, structured constraints are generated for failed or semantically inconsistent target repair patches through compilation and testing, and fed back to LLM for multiple rounds of adaptive optimization; and repeated iterations are performed until the target repair patch satisfies semantic consistency or reaches the iteration threshold.

[0073] In another embodiment of this application, a vulnerability repair system 300 for a Linux system is also provided.

[0074] In one possible implementation, Figure 3 This is a block diagram of a vulnerability repair system 300 for a Linux system provided in an embodiment of this application, as shown below. Figure 3 As shown, the vulnerability repair system 300 of the Linux system includes a generation module 301, a first processing module 302 and a second processing module 303.

[0075] For example, the generation module 301 is used to generate multiple candidate repair patches for repairing the target component based on the basic repair patch of the target component and the feature data that matches the target component; wherein, the feature data is data in the feature vector database that matches the target component, and the feature data is used to characterize at least all code change records and corresponding source code during the version iteration process of the target component.

[0076] For example, the first processing module 302 is used to obtain the quantitative evaluation value of each candidate repair patch, and determine the candidate repair patch with the highest quantitative evaluation value as the target repair patch; the quantitative evaluation value is associated with the repair effect of the candidate repair patch on the target component.

[0077] For example, the second processing module 303 is used to perform compilation testing on the target fix patch and fix the target component based on the compilation test results.

[0078] The following is for reference. Figure 4 , Figure 4 A schematic diagram of a communication device suitable for implementing embodiments of this application is shown, such as... Figure 4 As shown, the communication device 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage section 408 into a random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the system's operating instructions. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0079] The following components are connected to the input / output (I / O) interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the input / output (I / O) interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 410 as needed so that computer programs read from it can be installed into the storage section 408 as needed.

[0080] Specifically, according to embodiments of this application, the flowchart above refers to... Figures 1-2 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the functions defined in the system of this application.

[0081] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium compatible with computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0083] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor may be described as including a semantic extraction unit, a weight allocation unit, and a determination unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0084] On the other hand, this application also provides a computer-readable storage medium, which may be included in the communication device described in the above embodiments, or may exist independently and not assembled into the communication device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figures 1-2 The steps of the method shown.

[0085] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figures 1-2 The steps of the method shown.

[0086] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for patching vulnerabilities in a Linux system, wherein the vulnerabilities in the Linux system affect the normal operation of target components in the Linux system, characterized in that, The method includes: A retrieval statement is formed based on the basic repair patch of the target component and the feature data matching the target component. The retrieval statement is used as the input context to input the large language model, which then drives the large language model to infer and generate multiple candidate repair patches for repairing the target component. The feature data is data from a feature vector database that matches the target component. The feature data is obtained by semantic vectorization processing of a feature index file that includes function names, file paths, versions or commit identifiers, corresponding abstract syntax tree structure features, function call relationships, and historical change records. The feature data is used to characterize at least all code change records and corresponding source code of the target component during version iteration. For each candidate patch, a quantitative evaluation value is obtained, and the candidate patch with the highest quantitative evaluation value is determined as the target patch; wherein, the quantitative evaluation value is determined based on parameters of the candidate patch in four dimensions: patch effectiveness, logical compliance, engineering standardization, and evidence reliability; The target patch is compiled and tested, and the actual patch for the target component is obtained based on the compilation and test results; The actual patch for the target component obtained based on the compilation test results includes: If the compilation test result indicates that the target patch was compiled successfully and the target component is running normally, then the actual patch for the target component is determined to be the target patch; or, If the compilation test result indicates that the target patch failed to compile and / or the target component's running state is abnormal, the error features of the target patch are extracted, and the reason for the target patch's compilation failure is determined. Based on the reason for the compilation failure, structured constraint information of the target patch is generated. The structured constraint information and the target patch are input into a large language model for iterative adjustment until the adjusted target patch passes the compilation test. The iteratively adjusted target patch is then determined as the actual patch for the target component.

2. The method for patching vulnerabilities in a Linux system according to claim 1, characterized in that, The process of constructing the feature vector database corresponding to each target component includes: Obtain the baseline version source code, the high version source code, and all code change records between the baseline version source code and the high version source code of the target component, and parse the baseline version source code, the high version source code, and all code change records. Based on the parsing results, a corresponding abstract syntax tree structure is generated, and multiple feature index files are obtained based on the static features represented by the abstract syntax tree structure. Each of the aforementioned feature index files undergoes semantic vectorization processing to construct the feature vector database based on the feature data obtained from the processing.

3. The method for patching vulnerabilities in a Linux system according to claim 1, characterized in that, The compilation and testing of the target patch includes: The target patch is applied to the baseline version of the target component's source code for compilation and testing to obtain the compilation result of the target patch and the running status of the target component.

4. The method for patching vulnerabilities in a Linux system according to claim 1, characterized in that, The method further includes: If the number of iterations exceeds the preset number, the target repair patch after the previous iteration is determined as the actual repair patch for the target component.

5. A vulnerability remediation system for a Linux system, wherein a vulnerability in the Linux system affects the normal operation of a target component in the Linux system, characterized in that, The system includes: A generation module is used to form a retrieval statement based on the basic repair patch of the target component and the feature data matching the target component. The retrieval statement is input into a large language model as input context, and the large language model is driven to infer and generate multiple candidate repair patches for repairing the target component. The feature data is data in a feature vector database that matches the target component. The feature data is obtained by semantic vectorization processing of a feature index file that includes function name, file path, version or commit identifier, corresponding abstract syntax tree structure features, function call relationship, and historical change record. The feature data is used to characterize at least all code change records and corresponding source code during the version iteration process of the target component. The first processing module is used to obtain a quantitative evaluation value for each candidate repair patch, and determine the candidate repair patch with the highest quantitative evaluation value as the target repair patch; wherein, the quantitative evaluation value is determined based on parameters of the candidate repair patch in four dimensions: repair effectiveness, logical compliance, engineering standardization, and evidence reliability; The second processing module is used to compile and test the target patch, and repair the target component based on the compilation and test results; The actual patch for the target component obtained based on the compilation test results includes: If the compilation test result indicates that the target patch was compiled successfully and the target component is running normally, then the actual patch for the target component is determined to be the target patch; or, If the compilation test result indicates that the target patch failed to compile and / or the target component's running state is abnormal, the error features of the target patch are extracted, and the reason for the target patch's compilation failure is determined. Based on the reason for the compilation failure, structured constraint information of the target patch is generated. The structured constraint information and the target patch are input into a large language model for iterative adjustment until the adjusted target patch passes the compilation test. The iteratively adjusted target patch is then determined as the actual patch for the target component.

6. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1-4 to be implemented.

Images