MigGPT: Harnessing Large Language Models for Automated Migration of Out-of-Tree Linux Kernel Patches Across Versions

Thank you for your review comments. Your concerns regarding the discussion on MigGPT's generalization, IR-based approaches, and runtime overhead have all been addressed. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.

Weakness 1. Generalization of MigGPT

We appreciate you bringing up the crucial question of MigGPT's generalizability to other migration scenarios and domains. In response, we've incorporated new experimental findings:

• Demonstrated Generalizability to Other Migration Tasks: As explicitly detailed in Table 5 of our paper, MigGPT was successfully deployed in a CVE patch backporting task—specifically, migrating a CVE patch from its discovery version to an earlier iteration. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP. The results show that MigGPT consistently outperformed existing solutions.
• Enhanced Cross-Language Generalizability: We randomly selected 31 migration examples from our benchmark and translated them into Python. With only minimal modifications required for the statement tokenization and statement element extraction functions of CFP to accommodate Python syntax, MigGPT efficiently processed these examples. The results show an average semantic match performance improvement of 16.13% when compared to the vanilla approach, thereby underscoring MigGPT's robust effectiveness beyond its original C-language application.

Weakness 2. Runtime Overhead

We would like to thank the reviewer for the insightful comment. As shown in Table 6 of our manuscript, we conducted a comparison between MigGPT and human experts in terms of time cost for performing code migration tasks. The results demonstrate that MigGPT required only 2.08% of the average time taken by human experts. This highlights the capability of MigGPT to automate the code migration process, significantly reducing human effort and achieving substantial efficiency improvements.

Question 1. CFP and Intermediate Representations

Thank you for the suggestion. While IR-based methods are effective at normalizing syntax, CFP is designed to meet two essential needs in kernel patch migration:

• Context Preservation: Kernel patches often include macros, inline assembly, and annotations that are lost during IR generation. CFP retains this information, along with structural elements like function signatures and control-flow anchors, to give the LLM a richer migration context.
• Support for Non-Compilable Code: Early-stage or experimental patches may not compile, making IR extraction infeasible. CFP works directly on source code fragments, even if they are incomplete or broken.

Question 2. Generalization of MigGPT

Please refer to our response to Weakness 1

We are so pleased and grateful for your thoughtful feedback. Thank you! We have carefully considered your comments concerning MigGPT's generalization capabilities, symbolic representation, and deprecated system calls, and have provided thorough responses to each of these points. Please refer to the specific responses below and our rebuttal for more information.

Strength/Weakness Mixed. Generalization of MigGPT

Thank you for an insightful question about MigGPT's generalizability. We've strengthened our findings with new experiments:

• MigGPT Excels in Cross-Language Migration: To directly address concerns about its applicability beyond C-language, we rigorously tested MigGPT on Python code migration. By randomly translating 31 examples from our benchmark and making only minor adjustments for Python's syntax (specifically in tokenization and element extraction), MigGPT achieved a 16.13% average improvement in semantic match performance over traditional methods. This is a powerful testament to its cross-language capabilities.

• Proving Versatility Across Migration Challenges: Our original paper (Table 5) already showcased MigGPT's versatility through its successful application to CVE patch backporting. In this different, yet critical, migration task, MigGPT consistently outperformed existing solutions. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP.

Weakness 1. Symbol Notation (Response to Weakness 1)

We appreciate the reviewer's insightful feedback. To improve clarity and streamline the presentation, we will simplify ****the expression of this part. Thank you for helping us enhance the readability of our manuscript.

Weakness 2. AI4SE (Response to Weakness 2)

Your positive feedback and generous words regarding our work are truly appreciated! We're so pleased it resonated with you and had an impact. We focused on the intersection of AI and software engineering, as we believe this domain offers significant opportunities for practical impact. Our future plans include expanding this work to a broader range of code application areas, and we indeed plan to further delve into the SE aspects of our research and submit to a software engineering conference.

Question 1. Deprecated System Calls

Thank you very much for your insightful question. This is indeed a profound point that deserves thorough discussion.

Regarding your question about whether "out-of-tree patch-sets used now deprecated system calls" in our dataset, such instances are rare. This is primarily due to Linux kernel development principles prioritizing backward compatibility. Once a system call is added to the kernel, it's generally supported indefinitely to avoid breaking existing software that relies on it.

However, kernels do evolve, introducing new system calls that offer more robust, secure, or efficient functionalities. These new features can, in some cases, functionally supersede older, more limited mechanisms.

When a patch migration involves new system calls introduced in a newer kernel version, MigGPT is well-equipped to handle such scenarios. In these cases, the new version target code (s_new) will contain examples of how the new system call is used. MigGPT can then refer to these usage examples in s_new to complete the migration and generate a corresponding patch that aligns with the new API. Certainly, in this scenario, migration types can still be categorized according to the rules in Table 1 of the paper. If the new kernel version and patch modifications don't overlap in location, it's Type 1. Otherwise, it's Type 2.

Thank you for your thoughtful feedback. We have carefully considered your comments concerning the generation process of CFP, the generalization of MigGPT, failed cases of MigGPT, and the discussion of CFP. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.

Weakness 1. The Generation of CFP

The CFP generation algorithm is detailed in Algorithm 3 of Appendix D.4, as mentioned on line 232 of the manuscript. The supplementary materials also include the implementation code for CFP.

In brief, the CFP generation process involves the following steps:

• Tokenization and Scope Identification: The code snippet s is first tokenized. We identify nested code scopes (e.g., {} and #ifdef/#endif) via bracket matching.
• Code Block Demarcation: Critical symbols (e.g., {, }, #ifdef, func()) are used to demarcate different code blocks.
• Function Call Detection: Function calls are detected through pattern matching on token sequences, for instance, identifying an identifier followed by ().
• Associated Function Identification: We identify associated functions by analyzing call statements within code blocks, avoiding the need to construct complex call graphs.
• Preprocessor Macros: Preprocessor macros (e.g., #ifdef/#endif) are identified via specific keyword matching and treated as distinct code block boundaries.

We cannot provide a step-by-step example figure of the CFP generation process for you due to the rebuttal policy restrictions ("prohibit using any links in the rebuttal"), but following your advice, we will revise our paper to include such a figure. Thanks for your valuable suggestions.

Weakness 2. Baseline

Thank you for your question regarding the context window of LLMs. While LLMs with large contexts can process entire code files, they cannot analyze the structural information needed for code migration, such as target code structure information, migration point information, and patch difference information. As mentioned in Section 5.1 of our paper, there are challenges hindering LLMs’ success in out-of-tree kernel patch migration:

• Structural Ambiguity: LLMs struggle to accurately identify function definitions, often getting confused by similar structures.
• Boundary Indeterminacy: Inherent randomness in LLM-generated responses leads to inconsistencies between LLM-identified and human-retrieved target code snippet boundaries.
• Missing Associated Fragments: LLMs often overlook critical code fragments relevant to the migration, resulting in migration failures.
• Ambiguous Migration Points: LLMs cannot precisely identify and locate code migration points.

Our experimental results strongly demonstrate the necessity of CFP.

The baseline vanilla (”two-step strategy”) approach in Tables 2 and 3 is completely equivalent to MigGPT in terms of the context provided to the LLM, as both offer "the whole file" context relevant to migration. The only difference is that MigGPT uses CFP for the extraction and analysis of migration information, while “two-step” does not use CFP. The experimental data clearly shows that MigGPT improved the average migration accuracy by 45.92% compared to vanilla. This fully demonstrates the indispensable value of CFP abstraction in code migration tasks.

Weakness 3. Failure Cases

We agree that understanding these remaining failure modes is crucial for future advancements.

We've conducted an in-depth analysis of the "human match" errors and identified the following primary categories:

• Incomplete s_new Retrieval for Large Codebases (31.03%): In some instances, when retrieving s_new from new.c, the target code s_new was significantly large (exceeding 150 lines), leading to incomplete retrieval. This could be due to LLMs' tendency to shift attention when dealing with long contexts.
• Deviation from the Migration Point in s'_new Generation (24.14%): Even with precise migration point information provided by CFP, the LLM occasionally failed to strictly adhere to these locations during s'_new generation. While minor offsets often didn't impact functionality, they sometimes led to functional errors in code with complex control or data flows. This behavior appears to be related to the inherent randomness of LLMs.
• Difficulty in Fusing Divergent Changes in Type 2 Migrations (27.59%): For certain Type 2 migrations, significant differences between s_new and s_old's modifications to s_old prevented the LLM from correctly integrating these changes, resulting in errors. This limitation points to challenges related to the LLM's code comprehension and manipulation capabilities.
• Miscellaneous (17.24%): Errors in symbols, statements, etc., appearing in s'_new, such as incorrectly writing verbose(env, off, size, reg's id) instead of verbose(env, off, size, reg->id). This may be related to LLM hallucinations.

It's important to note that these identified failure modes primarily arise from the inherent limitations of the LLMs themselves, rather than architectural flaws within the MigGPT framework. We will incorporate this detailed failure analysis into the final version of our paper. Thank you again for your insightful feedback.

Weakness 4. Structured Analysis + LLMs

Thank you for your valuable feedback. We agree that explicitly situating our Code Fingerprint concept within the broader context of combining structured analysis and LLMs for code will strengthen the paper's contribution.

We have compared MigGPT with existing research in this emerging area. For instance, works such as [r-1, r-2] utilize heuristic tree structures to assist LLMs in optimizing kernel configurations during operating system deployment. Similarly, LLM-based fuzzing tools like [r-3, r-4, r-5] employ formal templates to guide LLMs in generating more effective test cases. These approaches, much like MigGPT, leverage deterministic information such as trees, graphs, and lists to mitigate the inherent uncertainty and randomness of LLMs, thereby improving performance across various application tasks. However, it's worth noting that the specific deterministic information used and its data structure are often tailored to the particular task at hand.

We will incorporate this discussion into the Related Work section of the final version of our paper.

[r-1] Chen H, Wen Y, Cheng L, et al. AutoOS: Make your os more powerful by exploiting large language models, Forty-first International Conference on Machine Learning. 2024.

[r-2] Lin H, Li Y, Luo H, et al. BYOS: Knowledge-driven Large Language Models Bring Your Own Operating System More Excellent. arXiv preprint arXiv:2503.09663, 2025.

[r-3] Xu H, Ma W, Zhou T, et al. CKGFuzzer: LLM-Based Fuzz Driver Generation Enhanced By Code Knowledge Graph, 2025 IEEE/ACM 47th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). IEEE, 2025: 243-254.

[r-4] J. Hu, Q. Zhang, and H. Yin, “Augmenting greybox fuzzing with generative AI,” arXiv preprint arXiv:2306.06782, 2023.

[r-5] Z. Liu, C. Chen, J. Wang, M. Chen, B. Wu, X. Che, D. Wang, and Q. Wang, “Testing the limits: Unusual text inputs generation for mobile app crash detection with large language model,” arXiv preprint arXiv:2310.15657, 2023.

Question 1. The Generation of CFP

Please refer to our response to Weakness 1

Question 2. Generalization of MigGPT

Thank you for your excellent question regarding MigGPT's generalizability across other tasks and domains. We've conducted new experiments to address this:

• Broad Migration Task Applicability: Our initial submission (Table 5) already demonstrated MigGPT's versatility by successfully applying it to CVE patch backporting—migrating patches to older code versions. In this scenario, MigGPT significantly outperformed existing methods. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP.
• Cross-Language Adaptability: We tested MigGPT's performance with Python code migration. After randomly translating 31 benchmark examples to Python and making minor adjustments to handle Python syntax (specifically in the statement tokenization and element extraction functions), MigGPT showed an average semantic match improvement of 16.13% over a vanilla approach. This confirms MigGPT's effectiveness beyond C-language code.

Question 3. Failure Cases

Please refer to our response to Weakness 3

Thanks for your valuable feedback. We've addressed your comments on MigGPT's generalization, the fairness of the "one-step strategy" comparison, additional migration scenarios, and cross-major-version migration. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.

Weakness 1. Generalization of the Framework

We thank you for raising an important question about the generalizability of MigGPT to other programming languages migration scenarios or other domains. Below, we have added a new experiment:

• Cross-Language Generalizability: To address the concern about cross-language generalizability, we conducted an additional experiment focusing on Python code migration. We randomly selected 31 migration examples from our benchmark and translated them to Python. With only minor adjustments (modify the implementation of the statement tokenization and statement element extraction functions) to adapt the CFP for Python syntax, MigGPT was able to process these examples. The results demonstrate that the average semantic match performance improved by 16.13%. compared to a vanilla approach, indicating MigGPT's effectiveness beyond C-language code.

• Generalizability to Other Migration Tasks: Our original submission already showcased MigGPT's applicability to other code migration tasks. As presented in Table 5 of our paper, MigGPT was successfully applied to the CVE patch backporting task (migrating a CVE patch from the version where the CVE was discovered to an older version). In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP. The results demonstrate MigGPT's superior performance compared to existing methods in this different migration scenario.

Weakness 2. Misunderstanding of the "One-step Strategy”

Apologize for the confusion, but we want to clarify that the contextual information given to the LLM is identical for both the "two-step strategy" (baseline vanilla approach in Tables 2 and 3) and the "one-step strategy", so the comparison is fair (details are shown in the table below). The contextual information includes the old version code s_old , s'_old and the new version file new.c. As shown in Figure 5 of the paper, the "two-step strategy" is clearly superior to the "one-step strategy".

To further address your concerns, we provided the key migration information extracted by CFP and the code information (s_old , s'_old, new.c) as context to the "one-step strategy" (One-step + CFP) and compared it with MigGPT (Two-step + CFP). As shown in the table below, formulating the migration task as a two-step process demonstrates performance advantages.

We recognize we didn't make this clear enough in the current paper, which likely led to this misunderstanding. We'll revise the manuscript to explicitly emphasize this alignment of contextual information for both strategies, ensuring readers fully understand the fairness of our comparison and our framework's true impact. Thanks for your valuable comment.

Question 1. More Migration Scenarios

We appreciate the reviewer's insightful question regarding more complex migration scenarios. Kernel subsystem refactoring: Indeed, our experiments already encompass kernel subsystem refactoring. For instance, our benchmarks include significant memory management subsystem changes, such as the introduction of folio and enhancements to io_uring. We also cover the process management subsystem's shift from CFS to EEVDF. These cases demonstrate our approach's effectiveness in handling substantial internal kernel restructuring.

Driver interfaces: While our paper primarily focuses on out-of-tree patch migration, we've conducted supplementary experiments to assess MigGPT's performance on these cases and address your concerns. We randomly collected 24 driver migration samples. The results, presented in the table below, indicate that MigGPT performs well in migrating patches involving driver interface modifications.

Question 2. Migrating Across Multiple Versions

Our benchmarks have already included the scenario where the target kernel version is quite different from the original. For instance, we demonstrate MigGPT's superior performance in migrating code from Kernel 5.10 to Kernel 6.6. This migration spans 15 versions (5.10, 5.11, …, 5.19, 6.0, 6.1, …, 6.6), clearly showing our tool's effectiveness across substantial version gaps.

Furthermore, Linux kernel development, and especially the maintenance of out-of-tree patches by vendors, typically focuses on Long-Term Support (LTS) versions (e.g., 4.19, 5.4, 5.10, 6.6). It's uncommon for vendors to directly develop and maintain patches across multiple, non-consecutive LTS versions. Our benchmarks specifically target migrations between these LTS versions, making them representative of real-world out-of-tree patch migration scenarios.

However, if an extreme case necessitates migrating across multiple LTS versions (e.g., from 4.19 to 6.6), an incremental migration strategy can be employed. A vendor could first use MigGPT to migrate from Kernel 5.4 to 5.10, rigorously test the migrated code, and resolve any bugs to ensure functionality. Subsequently, MigGPT could then be used for the migration from Kernel 5.10 to 6.6.