論文の概要: TyPatch: Transforming Patches into Typestate Rules for Kernel Bug Detection
- arxiv url: http://arxiv.org/abs/2609.13728v1
- Date: Sat, 12 Sep 2026 05:34:12 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-09-16 07:15:05.486523
- Title: TyPatch: Transforming Patches into Typestate Rules for Kernel Bug Detection
- Title（参考訳）: TyPatch: パッチをカーネルバグ検出のためのタイプステートルールに変換する
- Abstract要約: 我々はTyPatchを紹介し、パッチ固有の欠陥セマンティクスをアナライザの実装から分離する。
Linux v6.16では、TyPatchは559の異なるバグを発見し、そのうち121はカーネル開発者によって確認されている。
- 参考スコア（独自算出の注目度）: 9.241492644741198
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: Historical Linux kernel patches capture defect knowledge that applies beyond their original repair sites. Recent work has shown that large language models (LLMs) can generate static-analysis checkers from historical patches and use them to uncover new kernel bugs. However, complete-checker generation requires the model both to recover the defect semantics expressed by a patch and to implement sophisticated program-analysis machinery, including object tracking, alias analysis, path-state maintenance, and interprocedural propagation. Coupling these responsibilities in a single end-to-end code-generation task can turn a simple defect rule into an unstable and expensive analyzer-implementation problem. To address this problem, we present TyPatch, which decouples patch-specific defect semantics from analyzer implementation. An LLM translates each patch into a typestate rule specifying its tracked object, actions, guards, transitions, and violations. A shared backend then executes these rules, binding their actions to program events, tracking object identity across aliases, propagating typestate along program paths, and producing reports for all rules. On Linux v6.16, TyPatch finds 559 distinct bugs, 121 of which have been confirmed by kernel developers. In a matched 38-patch comparison with the state-of-the-art complete-checker construction workflow, TyPatch uses 88.3-90.1% fewer generation tokens, while its initial report pools achieve 3.42-14.95$\times$ the precision of those produced by that workflow.
- Abstract（参考訳）: 歴史的にLinuxカーネルのパッチは、元の修復現場を越えて適用される欠陥知識をキャプチャする。
最近の研究によると、大きな言語モデル(LLM)は過去のパッチから静的解析チェッカーを生成し、新しいカーネルのバグを発見できる。
しかし、完全チェッカー生成では、パッチによって表現される欠陥セマンティクスの復元と、オブジェクト追跡、エイリアス解析、パス状態の保守、相互伝達といった高度なプログラム分析機構の実装の両方が要求される。
これらの責務を1つのエンドツーエンドのコード生成タスクにまとめることで、単純な欠陥ルールを不安定で高価なアナライザ実装の問題に変換することができる。
この問題に対処するために、パッチ固有の欠陥セマンティクスをアナライザの実装から分離するTyPatchを提案する。
LLMは各パッチを、追跡されたオブジェクト、アクション、ガード、トランジション、違反を指定する型ステートルールに変換する。
共有バックエンドはこれらのルールを実行し、アクションをプログラムイベントにバインディングし、エイリアスを越えてオブジェクトのアイデンティティを追跡し、プログラムパスに沿って型ステートを伝搬し、すべてのルールのレポートを生成する。
Linux v6.16では、TyPatchは559の異なるバグを発見し、そのうち121がカーネル開発者によって確認されている。
最先端のフルチェッカー構成ワークフローと比較した38パッチでは、TyPatchは88.3-90.1%少ない生成トークンを使用し、最初のレポートプールは3.42-14.95$\times$.42-14.95$\timesである。
関連論文リスト
- The History Is the Detector: Executing CVE Patch History, End-to-End [7.5252436225607875]
本稿では,脆弱性履歴を実行可能な検出ルールに変換するフレームワークBUGSTONE-E2Eを提案する。
BUGSTONE-E2Eは、2022年から2026年にかけて19,325個の高重度CVEを使用して、2,710個の修正コミットを特定し、1,033個の検出ルールを構築している。
14のプログラムに適用すると、644の発見のランタイムエビデンスを生み出した。
論文 参考訳（メタデータ） (2026-09-04T16:40:22Z) - Independent Patch Verification for Coding Agents with a Bidirectional Reconstruct-and-Verify Framework [49.16055123488827]
大規模言語モデルを利用したコーディングエージェントは、バグレポートから直接コードパッチを生成することができる。
報告された問題を真に解決するかどうかを独立に検証するメカニズムは存在しない。
本稿では,RETRACE をトレーニング不要なポストジェネレーション検証フレームワークとして提案する。
論文 参考訳（メタデータ） (2026-08-09T22:59:13Z) - ContraFix: Agentic Vulnerability Repair via Differential Runtime Evidence and Skill Reuse [10.503895811137095]
大規模言語モデル(LLM)エージェントは、自動脆弱性修復にますます利用されている。
最近の実証的な結果は、これらのエージェントがいまだに現実世界の脆弱性と戦っていることを示している。
ContraFixは、再利用可能な修復スキルとランタイムエビデンスを結合するエージェントフレームワークである。
論文 参考訳（メタデータ） (2026-05-17T13:48:25Z) - Dynamic analysis enhances issue resolution [53.50448142467294]
DAIRA(Dynamic Analysis-enhanced Issue Resolution Agent)は、エージェントの推論サイクルに動的解析を組み込む自動修復フレームワークである。
テストトレース駆動の方法論によって駆動されるDAIRAは、軽量モニタを使用して重要なランタイムデータを抽出する。
Gemini 3 Flash Previewを使用すると、DAIRAは新たな最先端(SOTA)パフォーマンスを確立し、SWE-bench Verifiedデータセットで79.4%の解像度を達成する。
論文 参考訳（メタデータ） (2026-03-23T14:48:54Z) - AlgoVeri: An Aligned Benchmark for Verified Code Generation on Classical Algorithms [54.99368693313797]
既存のベンチマークでは、個々の言語/ツールのみをテストするため、パフォーマンス番号は直接比較できない。
このギャップに対処するAlgoVeriは、Dafny、Verus、Leanで77ドルの古典的アルゴリズムのベリコーディングを評価するベンチマークです。
論文 参考訳（メタデータ） (2026-02-10T06:58:26Z) - PatchGuru: Patch Oracle Inference from Natural Language Artifacts with Large Language Models [16.633386478990037]
PatchGuruは、実際のプルリクエスト(PR)から実行可能なパッチ仕様を推論する最初の自動テクニックである。
PRが与えられた後、PatchGuruは大規模な言語モデル(LLM)を使用してNLアーティファクトから開発者の意図を抽出し、パッチオークルを合成する。
PatchGuruは、プレパッチとポストパッチの動作を比較し、違反を特定し、自己レビューを通じて不整合をフィルタリングし、バグレポートを生成することで、推論されたオラクルを反復的に洗練する。
論文 参考訳（メタデータ） (2026-02-05T03:48:17Z) - 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) - Probing Pre-trained Language Models on Code Changes: Insights from ReDef, a High-Confidence Just-in-Time Defect Prediction Dataset [0.0]
本稿では,22の大規模C/C++プロジェクトから得られた関数レベル修正の信頼性の高いベンチマークであるReDefを紹介する。
欠陥ケースはコミットの反転によって固定され、クリーンケースはポストホック履歴チェックによって検証される。
このパイプラインは3,164の欠陥と10,268のクリーンな修正をもたらし、既存のリソースよりも信頼性の高いラベルを提供する。
論文 参考訳（メタデータ） (2025-09-11T07:07:11Z) - RAP-Gen: Retrieval-Augmented Patch Generation with CodeT5 for Automatic
Program Repair [75.40584530380589]
新たな検索型パッチ生成フレームワーク(RAP-Gen)を提案する。
RAP-Gen 以前のバグ修正ペアのリストから取得した関連する修正パターンを明示的に活用する。
RAP-GenをJavaScriptのTFixベンチマークとJavaのCode RefinementとDefects4Jベンチマークの2つのプログラミング言語で評価する。
論文 参考訳（メタデータ） (2023-09-12T08:52:56Z) - Patch Space Exploration using Static Analysis Feedback [8.13782364161157]
静的解析を利用して、メモリの安全性問題を自動的に修復する方法を示す。
提案したアプローチは、バグを修正するためのパッチの近さを検査することで、望ましいパッチが何であるかを学習する。
我々は,印字ヒープに対する影響に応じて等価パッチのクラスを作成し,そのクラスのパッチ等価度に対してのみ検証オラクルを呼び出すことにより,修復をスケーラブルにする。
論文 参考訳（メタデータ） (2023-08-01T05:22:10Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。