rsyncプロジェクトはバージョン3.5.2をリリースしました。接続してきたクライアントが、どこにもたどり着かないチェックサム計算でサーバーのCPUを占有できてしまう脆弱性を修正しています。新バージョンでは、転送処理のCPUとディスクの優先度を最後尾に下げることもできるようになり、大規模な同期が同じマシン上の他の処理を圧迫しにくくなります。
rsyncは、ローカルおよびネットワーク越しにファイルをコピーするオープンソースのユーティリティです。ソフトウェアアーカイブのミラーリングやバックアップに広く使われています。ファイルのうち変更された部分だけを送信して転送量を抑えるため、低速な回線でも実用的に使えます。受信側は手元のファイルをブロックに分割し、各ブロックについて軽量なローリングチェックサムと、より強力なチェックサムを送信側に送ります。送信側は自身のファイル上でウィンドウをずらしながら、まず軽量なチェックサムで照合し、一致した場合にだけ強力なチェックサムを計算して、ブロックが同一であることを確認します。
脆弱性CVE-2026-119741は、このループ内にあります。具体的には、match.cのhash_search()です。悪意ある受信側が、ローリングウィンドウのたびに衝突する弱いチェックサムと、一致しない強いチェックサムを組み合わせて送信します。すると送信側は、失敗に終わる強力なチェックサムを延々と計算し続けます。数本の接続が同時に行われるだけで、CPUは使い尽くされます。影響を受けるのは、3.5.1までのすべてのバージョンです。IDを割り当てたVulnCheckは、この問題を非効率なアルゴリズムの複雑性に分類しています。CVSS 4.0では8.7、CVSS 3.1では7.5とスコアリングされ、影響はすべて可用性に及び、データへの影響はありません。
公開デーモンモジュールを運用している場合、アカウントがなくても誰でもこの攻撃を実行できます。ファイルを取得させることが、そもそもモジュールの目的だからです。
バージョン3.5.2では、プロセス優先度の制御も追加されました。新しい--niceオプションと--no-niceオプションにより、ローカルプロセス、リモートプロセス、またはその両方に対して、CPUとI/Oのスケジューリング優先度を設定できます。2つの値は互いに独立して組み合わせられます。デーモンのクライアントが要求できるのは、CPUのnice値19、アイドルI/O優先度、またはその両方に限られます。制限付きSSHラッパーのrrsyncが受け付けるのは、ローカル側での優先度の引き下げのみです。ローカルでの変更がサポートされていない場合や拒否された場合、rsyncは警告を表示したうえで転送を続行します。リモート側の設定には、それに対応したピアが必要です。一方、ローカルのみの設定は、古いピアとの間でも利用できます。
翻訳元: https://www.helpnetsecurity.com/2026/11/04/rsync-3-5-2-released/
