論文の概要: SoK: From Finding to Deployment: Systematizing the OS Kernel Bug Lifecycle

• arxiv url: http://arxiv.org/abs/2609.23218v1
• Date: Sat, 19 Sep 2026 21:25:07 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-09-24 17:01:17.812158
• Title: SoK: From Finding to Deployment: Systematizing the OS Kernel Bug Lifecycle
• Title（参考訳）: SoK: 発見からデプロイへ:OSカーネルバグライフサイクルの体系化
• Abstract要約: このSoKは、発見からデプロイまでのLinuxカーネルのバグライフサイクルをシステム化する。 我々は、実際のsyzbot固定バグの測定結果に基づいて解析を行った。 これにより、カーネルのセキュリティ自動化が成熟した場所と、バグのクロージャが実際に停止した場所とのミスマッチが露呈する。
• 参考スコア（独自算出の注目度）: 2.113362023794639
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Automated kernel bug discovery has advanced rapidly. Continuous fuzzing and static analysis systems, such as syzbot, now expose Linux kernel bugs at a scale that downstream processes struggle to absorb. Yet a crash report is only the beginning. Before a bug is eliminated, it must be triaged, understood, patched, validated, reviewed, integrated, and often backported. These later stages remain far less automated, creating a persistent gap between bug discovery and patch deployment. This SoK systematizes the Linux kernel bug lifecycle from discovery to deployment. We organize prior work and production systems into five stages: discovery, triage, patch generation, patch validation, and integration. We explain the resulting automation gradient through kernel-specific challenges such as concurrency, implicit invariants, cross-syscall state, hardware dependence, lack of fault isolation, and architecture/configuration multiplicity. We further ground the analysis in a measurement of real syzbot-fixed bugs. The data shows that the crash-to-patch gap is not merely a backlog of unfixed reports but a structural failure mode of the repair pipeline: even after being fixed, bugs often remain open for weeks, require review-driven patch revisions, or lack reproducers that current repair and validation systems assume. This exposes a mismatch between where kernel-security automation is mature and where bug closure actually breaks down. These findings expose a deeper mismatch: today's repair and validation techniques often assume reliable reproducers, localized root causes, and checkable correctness oracles, yet these are precisely the artifacts missing from many real kernel bug reports. Closing the crash-to-patch gap, therefore, requires treating such artifacts as outputs to be produced, not prerequisites to be assumed.
• Abstract（参考訳）: 自動カーネルバグ発見は急速に進歩した。 syzbotのような継続的ファジィングと静的解析システムは、ダウンストリームプロセスが吸収に苦しむスケールでLinuxカーネルのバグを公開する。 しかし、クラッシュレポートは始まりにすぎない。 バグが除去される前に、トリアージされ、理解され、パッチが適用され、検証され、レビューされ、統合され、しばしばバックポートされなければならない。 これらの後期段階は依然としてずっと自動化されておらず、バグ発見とパッチのデプロイの間に永続的なギャップを生じさせる。 このSoKは、発見からデプロイまでのLinuxカーネルのバグライフサイクルをシステム化する。 私たちは、事前の作業と運用システムを、発見、トリアージ、パッチ生成、パッチ検証、統合の5つのステージにまとめています。 並列性、暗黙の不変性、クロスサイスコール状態、ハードウェア依存、フォールトアイソレーションの欠如、アーキテクチャ/コンフィギュレーションの多重性など、カーネル固有の課題による自動化の勾配について説明する。 さらに、実際のsyzbot固定バグの測定で解析を下方修正する。 データによると、クラッシュ・ツー・パッチのギャップは、単に修正されていないレポートのバックログではなく、修復パイプラインの構造的な障害モードである。 これにより、カーネルのセキュリティ自動化が成熟した場所と、バグのクロージャが実際に停止した場所とのミスマッチが露呈する。 今日の修復と検証のテクニックでは、信頼できるレプリケータ、ローカライズされた根本原因、チェック可能な正当性オラクルを前提としていますが、これはまさに多くの実際のカーネルバグレポートから欠落しているアーティファクトです。 したがって、クラッシュ・ツー・パッチのギャップを閉じるには、そのような成果物を前提条件ではなく、出力として扱う必要がある。

関連論文リスト

• Beyond Fail-to-Pass: Iterative Hardening of Co-Generated Bug Reproduction Tests and Fixes [55.114939648705395]
  大規模言語モデル(LLM)は、現実のバグに対して、プログラムの自動修正をますます実用的にしている。 バグ再現テスト(BRT)は、バグレポートを実行可能なバグ固有の信号に変換することで、このギャップを埋めるのに役立つ。 本稿では,ループ内収束基準としてLax信号を用いるコジェネレーションフレームワークであるCoHardenを提案する。
  論文  参考訳（メタデータ） (2026-07-22T07:30:07Z)
• Beyond Crash-to-Patch: Patch Evolution for Linux Kernel Repair [2.267311896805228]
  Linuxカーネルの修正は、受け入れ前にメーリングリストの反復的なリビジョンが行われ、レビュアーからのフィードバックが正確さ、ハンドリング、APIコンプライアンスを形作る。 6946 syzbot-linked bug-fix cyclesを再構築し,カーネルパッチの進化に関する大規模な研究を行った。 我々は、検索ベースのメモリと微調整された診断アドバイザを統合する修復フレームワークであるPatchAdvisorを開発し、コードエージェントをレビュアー対応パッチへ誘導する。
  論文  参考訳（メタデータ） (2026-04-04T20:23:32Z)
• Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
  Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。 kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。 kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
  論文  参考訳（メタデータ） (2026-02-02T19:06:15Z)
• What Do They Fix? LLM-Aided Categorization of Security Patches for Critical Memory Bugs [46.325755802511026]
  我々は、LLM(Large Language Model)と細調整された小言語モデルに基づく2つのアプローチを統合するデュアルメタルパイプラインであるLMを開発した。 LMは、OOBまたはUAFの脆弱性に対処する最近のLinuxカーネルのパッチ5,140のうち111つを、手作業による検証によって90の正の正が確認された。
  論文  参考訳（メタデータ） (2025-09-26T18:06:36Z)
• CrashFixer: A crash resolution agent for the Linux kernel [58.152358195983155]
  この作業は、システムレベルのLinuxカーネルバグのベンチマークと、Linuxカーネルで実験を実行するプラットフォームを共有するkGymの上に構築されている。 CrashFixerはLinuxカーネルのバグに適応する最初のLCMベースのソフトウェア修復エージェントである。
  論文  参考訳（メタデータ） (2025-04-29T04:18:51Z)
• Fast Fixes and Faulty Drivers: An Empirical Analysis of Regression Bug Fixing Times in the Linux Kernel [3.1959458747110054]
  本稿では、回帰バグの修正に要する時間を考慮して、カーネルの回帰バグ追跡に焦点を当てる。 調査したデータセットは、Linuxカーネルのレグレッションを追跡するregzbot自動化フレームワークに基づいている。
  論文  参考訳（メタデータ） (2024-11-04T13:53:29Z)
• KGym: A Platform and Dataset to Benchmark Large Language Models on Linux Kernel Crash Resolution [59.20933707301566]
  大規模言語モデル(LLM)は、ますます現実的なソフトウェア工学(SE)タスクにおいて一貫して改善されている。 現実世界のソフトウェアスタックでは、Linuxカーネルのような基本的なシステムソフトウェアの開発にSEの取り組みが費やされています。 このような大規模システムレベルのソフトウェアを開発する際にMLモデルが有用かどうかを評価するため、kGymとkBenchを紹介する。
  論文  参考訳（メタデータ） (2024-07-02T21:44:22Z)
• RaceFixer -- An Automated Data Race Fixer [0.0]
  RaceFixerは、ひとつの一般的なタイプのバグを修正するプロセスを自動化する。 複数のバグのパッチを組み合わせることで、パフォーマンスとコードの可読性を向上する。
  論文  参考訳（メタデータ） (2024-01-08T20:25:14Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。