Applying a patch with a fuzzFactor can be very very slow

オープン
#692 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@json-open-source がすでに取り組んでいます。

2026年10月1日 から。

  • #711 @json-open-source による — オープン
  • #716 @anzal1 による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
security

調査の方向性

applyPatch(...) と applyPatches(...) のエントリポイントから始め、レポートで説明されている fuzzy patch matching ロジックをたどります。低下を測定するために、control ケースと作成した high-fuzzFactor ケースを再現します。作成した fuzzy パッチが過剰な CPU 時間を消費しなくなり、通常の fuzzy 適用動作が維持されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

performance

Thanks to the following five security researchers for reporting this:

Finding 1: Fuzzy patch application can cause algorithmic complexity DoS
Affected behavior

applyPatch and applyPatches support fuzzy patch matching. With crafted hunks and a high fuzzFactor, the matching logic can end up exploring many alternatives recursively and spend a large amount of CPU time on a single input.

Affected entrypoints

`applyPatch(...)`
`applyPatches(...)`

Reproduction notes
In our reproduction, a normal control case completed in under 1 ms, while a crafted fuzzy patch took about 7.7 seconds on the same setup:

control time: 0.568181 ms
exploit time: 7737.472789 ms
slowdown: 13617.9717x

The issue appears to come from recursive branch exploration in the fuzzy patch application logic.

主要言語
JavaScript
スター
9.2k
フォーク
555
平均マージ
1日 9時間
マージ済み PR(30日)
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

kpdecker/jsdiff のほかの issue

kpdecker/jsdiff の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。