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

1 Introduction

• Out-of-tree patches adapt the kernel to specific uses, but maintaining compatibility across versions can demand weeks of expert effort.The paper names RT-PREEMPT, AUFS, HAOC, Raspberry Pi kernel, and Open vSwitch as examples.Source: §1 · p. 1
• Direct LLM migration is challenged by structural similarity, unstable snippet boundaries, missing associated-code information, and inaccurate migration-point locations.These challenges reflect incomplete code-context understanding and inaccurate identification of where patches should be migrated.Source: §1 · p. 2
• MIGGPT reframes migration as retrieving target code in the updated kernel and then migrating the patch, using Code Fingerprints across three modules.Retrieval Augmentation supplies snippet information, Retrieval Alignment uses first and last anchor lines to align boundaries, and Migration Enhancement compares fingerprints to locate migration points.Source: §1 · p. 2
• 74.07% average completion rate (↑45.92%) over vanilla LLMs, with 2.08% of the average human-expert time required.The evaluation also reports an average of 2.26 LLM queries (↑0.26), indicating no substantial increase in computational overhead.Source: §1 · p. 2
• The benchmark uses three real-world projects and is presented as the first tool-diverse benchmark for out-of-tree kernel patch migration.It provides a basis for assessing diverse migration tools and future research.Source: §1 · p. 2
• 74.07% average migration accuracy (↑45.92%) demonstrates MIGGPT’s improvement over vanilla LLMs.The evaluated models included both closed-source GPT-3.5, GPT-4, and OpenAI-o1, and open-source DeepSeek-V3, DeepSeek-R1, and Llama-3.1.Source: §1 · p. 3

2.1 Code Migration Kernel Patch

• Existing migration tools focus on API maintenance and CVE backporting, but predefined rules and known-location assumptions limit their coverage of out-of-tree patch migration.Those approaches can miss namespace changes, invocation conflicts, and control- or data-flow dependencies; MIGGPT instead treats retrieval and migration as a two-step task.Source: §2.1 · p. 3

2.2 LLMs for Coding

• Progress in LLM coding capabilities motivates their use for out-of-tree patch migration, which the authors describe as MIGGPT’s first application of LLMs.The cited capabilities include code completion, search, summarization, generation, and repair.Source: §2.2 · p. 3

3 Problem Formulation

• Migration constructs a function that carries a patched old-version kernel repository to a compatible patched repository for the new kernel version.Out-of-tree patches lack official support and require manual maintenance for compatibility with future kernel versions.Source: §3 · p. 3
• Table 1 formalizes and counts two migration types, while excluding simpler cases that do not need resolution.The supplied table caption identifies the two types and says other cases are too simple to necessitate resolution.Source: Table 1 · p. 3

4.1 Migration Types

• Type 1 migrations have non-overlapping patch and kernel edits, whereas Type 2 migrations have overlapping edits that conflict.Cases with no patch change or no kernel-version change are excluded as straightforward migrations.Source: §4.1 · p. 4

4.2 Benchmark Design

• The benchmark draws from RT-PREEMPT, Raspberry Pi Linux, and HAOC across Linux kernel versions 4.19, 5.4, 5.10, and 6.6.The selected versions are officially maintained LTS releases used in production systems.Source: §4.2 · p. 4
• The benchmark contains 135 migration examples: 80 Type 1 and 55 Type 2.Examples are collected as old and patched code, a new-version file, and human-completed target and migrated code; invalid differences such as whitespace and file deletions are filtered out.Source: §4.2 · p. 4

5.1 Challenges

• Similar function structures can mislead retrieval, while omitted associated functions leave retrieved code snippets incomplete.The retrieval augmentation module uses function signatures and retrieves newly called associated functions to augment the snippet.Source: §5.1 · pp. 4–5, §5.4 · p. 6
• Unstable snippet boundaries can omit or add lines, and LLMs may misidentify the location of patch migration points.The alignment module uses the old snippet’s first and last lines; the migration augmentation module uses old and modified snippets to locate migration points.Source: §5.1 · pp. 4–5, §5.5 · p. 7, §5.6 · p. 7

5 MIGGPT

• MIGGPT uses a code fingerprint structure across three modules to support target-code retrieval and patch migration in two stages.The modules address retrieval errors, snippet-boundary mismatch, and ambiguous migration points.Source: §5.3 · p. 5, Figure 2 · p. 5

5.3 Code Fingerprint

• CFP encodes structural features while focusing on migration-relevant statements and retaining comments and inline assembly that AST analysis may miss.AST tools can require complete compilation dependencies and provide excessive irrelevant detail.Source: §5.3 · pp. 5–6

5.4 Retrieval Augmentation Module

• The retrieval augmentation module uses old-snippet function signatures to guide retrieval and adds newly called associated functions missing from the temporary result.It compares called-function sets from the temporary and old snippets, then retrieves matching function code from the new-version file.Source: §5.4 · p. 6

5.5 Retrieval Alignment Module

• The retrieval alignment module uses CFP statements from the old snippet’s first and last lines to guide identification of the new snippet’s boundaries.These statements form an Alignment Prompt for the LLM.Source: §5.5 · p. 7

5.6 Migration Augmentation Module

• The migration augmentation module uses differences between the old snippet and its modified counterpart to prompt identification of migration-point number and location.This information is encoded in a Location Prompt for the LLM.Source: §5.6 · p. 7

5.7 Implementation

• Implementation forms a Retrieval Prompt from CFP-derived signatures and anchors, checks the initial result, and augments it before migration.It retries retrieval up to m times if the result lacks target signatures, then uses CFP differences to form a Location Prompt and query the LLM for the migrated patch.Source: §5.7 · p. 7

6.1 Evaluation Settings

• MIGGPT is evaluated on two benchmarks against vanilla LLMs and prior migration tools, using best match, semantic match (CodeBLEU threshold 0.9), human match, and compilation success rate.One benchmark is FixMorph’s CVE patch backporting benchmark, which includes 350 instances.Source: §6.1 · pp. 7–8

6.2 Performance Evaluation (RQ1)

• 84.55% average semantic matching precision is reported for target-code retrieval, a 20.53% relative improvement; GPT-4-turbo with MIGGPT reaches 96.25% human matching precision for Type 1 samples versus 65.00% for standalone GPT-4-turbo.The comparison covers retrieval accuracy for MIGGPT-augmented and vanilla LLMs.Source: Table 2 · p. 8, §6.2 · p. 8
• 73.12% higher average migration semantic matching precision (45.61% relative improvement) is reported for MIGGPT over vanilla LLMs.MigGPT-augmented Llama-3.1-8B still achieves 44.44% higher semantic matching precision than vanilla Llama-3.1-8B.Source: Table 3 · p. 8, §6.2 · pp. 8–9
• 12.22% average migration accuracy for vanilla LLMs using the two-step strategy exceeds the one-step strategy’s 3.33% by 8.89%.Figure 5 covers semantic match accuracy for retrieval and migration across LLMs; “one-step” means direct single-step migration.Source: Figure 5 · p. 8, §6.2 · p. 9
• MIGGPT reports a 48.49% average improvement in compilation success rate over vanilla LLMs and outperforms prior patch-backporting methods on CVE patch backporting.The CVE task differs from out-of-tree migration because the latter includes both target-code retrieval and migration.Source: Table 4 · p. 9, §6.2 · p. 9, Table 5 · p. 9
• MIGGPT performs well on driver migrations involving interface modifications and improves average semantic match performance on Python migration by 16.13% over a vanilla approach.For Python, the framework required minor CFP adjustments to statement tokenization and statement-element extraction.Source: Table 6 · p. 9, §6.2 · p. 9, Table 7 · p. 9

6.4 Ablation Study

• MIGGPT consistently outperforms four tested ablation variants, and m = 3 is suitable for both Type 1 and Type 2 examples.The four units tested are CFP, Retrieval Augmentation, Retrieval Alignment, and Migration Augmentation; m controls Retrieval Augmentation’s total query time.Source: §6.4 · p. 9, Figure 6 · p. 10

6.5 Failure Analysis (RQ3)

• Failure analysis identifies incomplete retrieval for large codebases (31.03%), deviation from the migration point (24.14%), divergent Type 2 changes (27.59%), and miscellaneous errors (17.24%).For incomplete retrieval, the target snippet exceeded 150 lines; migration-point deviations occurred despite precise CFP information, and divergent modifications sometimes prevented correct integration.Source: §6.5 · p. 10

• The study examines out-of-tree Linux kernel patch migration across versions.Source: §7 · p. 10
• The benchmark reveals that LLMs struggle with incomplete code-context understanding and inaccurate migration-point identification.Source: §7 · p. 10
• MigGPT is proposed as an automated tool for migrating Linux kernel downstream patches, and evaluation highlights its effectiveness and potential.Source: §7 · p. 10

• Benchmark examples come from RT-PREEMPT, HAOC, and Raspberry Pi kernel, three open-source out-of-tree patch projects.Source: §A.1 · p. 16
• The projects cover real-time performance, kernel security, and embedded-system optimization use cases.RT-PREEMPT targets timing-sensitive applications; HAOC uses a dual-kernel security design, while Raspberry Pi Linux is optimized for embedded systems.Source: §A.1 · p. 16
• Although RT-PREEMPT's latest version entered mainline Linux maintenance, the authors still use it for migration and maintenance research.Source: §A.1 · p. 16

A.2 Examples of Benchmark

• Type 1 migrations contain changes to both the patch and kernel code, but those changes do not overlap; Type 2 changes overlap and conflict.Source: §A.2 · p. 16

B Examples of Out-of-tree Kernel Patch Migration

• Migration combines changes from the old out-of-tree patch with modifications in the new kernel to produce the updated patch code.Source: B Examples of Out-of-tree Kernel Patch… · p. 17, Figure 7 · p. 17

C.1 Challenge 1; C.2 Challenge 2

• Similar function definitions can mislead retrieval, while incomplete line-range retrieval can omit needed code.The examples show confusion between __pte_free_tlb and __pmd_free_tlb, and retrieval of only lines 7–10 when the target spans lines 4–10.Source: §C.1 · p. 17, §C.2 · p. 18

C.3 Challenge 3; C.4 Challenge 4

• Code fragmentation can hide a patch's true migration location, and some migrations require multiple precisely placed modifications.Source: §C.3 · pp. 18–19, §C.4 · p. 19, Figure 11 · p. 19

D.1 Examples of CFP

• A CFP can encode an #ifdef node's span and critical identifier, as illustrated by the ARM_64_SWAPPER_USES_MAPS example.Source: §D.1 · p. 19, Figure 12 · p. 20

D.2 Examples of Retrieval Augmentation Module

• Retrieval augmentation uses function signatures to distinguish similar targets and adds invoked functions missing from an initial retrieval, excluding calls already present in the old snippet.Source: §D.2 · pp. 19–20

D.3 Examples of Migration Augmentation Module

• Migration augmentation compares old and patched code fingerprints to identify two migration locations and construct a Location Prompt.Source: §D.3 · p. 20

D.4 Algorithm and Prompts; D.5 CFP

• The workflow builds retrieval and migration prompts around task, structure, alignment, location, and expert-persona guidance; CFP generation identifies scopes, statements, and function calls through token and pattern analysis.Source: §D.4 · pp. 20–21, §D.5 · pp. 21–22

E More Results of MIGGPT

• MIGGPT outperforms the vanilla LLM on target-code-snippet retrieval in the DeepSeek-V2.5 experiments.Source: E More Results of MIGGPT · p. 22, Table 11 · p. 22

F.1 Platform

• Experiments used an AMD Ryzen 9 7900X 12-core CPU with 32GB RAM.Source: §F.1 · p. 22
• The experimental system ran Ubuntu 22.04.3 LTS.Source: §F.1 · p. 22

F.2 Contextual Information

• The two-step strategy outperforms “One-step + CFP” when both receive identical contextual information.The comparison is MigGPT (Two-step + CFP) versus One-step + CFP.Source: §F.2 · pp. 22–23

F.3 The Reliability of Human Match

• Human Match evaluation uses syntactic consistency and semantic correctness criteria, with three randomly assigned engineers evaluating each example.Five experienced Linux kernel engineers independently validate results.Source: §F.3 · p. 23

F.4 Compilation Success Rate

• Compilation success rate is the share of migration samples whose generated patches compile in a containerized new-kernel environment.The denominator is all types of migration examples.Source: §F.4 · p. 24

F.5 Line Edit Distance

• Line edit distance measures the minimum single-line insertions, deletions, or substitutions needed to transform one code snippet into another.Its recursive cases correspond to deletion, insertion, and substitution.Source: §F.5 · p. 24

F.6 Threshold of CodeBLEU

• 0.9 is the identified optimal CodeBLEU threshold for consistency between automated semantic matches and human matches on this benchmark.Table 15 presents results under CodeBLEU semantic-match and human-match classifications.Source: §F.6 · p. 24, Table 15 · p. 25

F.7 Variant of MIGGPT

• The ablation variants disable retrieval augmentation, retrieval alignment, migration augmentation, or CFP-dependent components, respectively.These variants remove snippet-structure constraints, boundary descriptions, additional migration analysis, or CFP-based analyses.Source: §F.7 · p. 25

G.1 Type 1 Migration Sample

• Traditional static-alignment methods struggle with Type 1 migrations when code moves across function boundaries, as in the compute_stats() example.The example describes compute_stats() becoming standalone while FixMorph’s AST differencing assumes code blocks remain within the same function.Source: §G.1 · p. 25, Figure 17 · p. 26

G.2 CFP and Intermediate Representations

• CFP preserves kernel macros, inline assembly, annotations, function signatures, and control-flow anchors that IR generation may strip, while supporting non-compilable source fragments.This addresses context needs that syntax normalization alone does not cover.Source: §G.2 · p. 26

G.3 Generalization of MIGGPT

• MIGGPT’s CFP combines kernel-specific optimizations with a methodology the authors describe as extensible to CVE backporting and forked-code porting.The described kernel adaptations include inline assembly, kernel macro patterns, comment conventions, and function chaining.Source: §G.3 · p. 26

G.4 Structured Analysis of CFP

• Structured representations such as trees, graphs, and lists can provide deterministic guidance to LLMs, but their specific forms are often task-tailored.The passage compares this broader approach with MigGPT and examples in kernel configuration and fuzzing.Source: §G.4 · p. 26

G.5 Deprecated System Calls

• For migrations involving newer system calls, MigGPT can use examples in the target code to generate a patch aligned with the new API.The migration remains Type 1 or Type 2 depending on whether target-kernel and patch modifications overlap in location.Source: §G.5 · p. 27

G.6 Impact Statement

• The authors suggest MIGGPT may reduce manual effort and costs, while noting that automated critical maintenance requires rigorous validation and may affect engineering roles.They frame these as potential benefits and ethical considerations, respectively.Source: §G.6 · p. 27