Rustベースのcoreutilsの日付バグでUbuntu 25.10の自動更新が停止

 (lwn.net)
2 ポイント 投稿者 GN⁺ 2025-10-25 | 1件のコメント | WhatsAppで共有
  • Ubuntu 25.10で、Rustで書かれたcoreutils（uutils） の date コマンドのバグにより、一部システムで 自動更新機能が動作しない問題 が発生
  • このバグは rust-coreutils パッケージ 0.2.2-0ubuntu2 以下のバージョン で見つかっており、0.2.2-0ubuntu2.1 以降のバージョン で修正済み
  • 問題は クラウド展開、コンテナイメージ、デスクトップおよびサーバーのインストール環境 のすべてに影響したが、apt コマンドによる 手動更新には影響しない
  • Ubuntuは今回のリリースで、Rustベースのユーティリティ（uutils、sudo-rs） への移行を試験しており、これは来年の 長期サポート（LTS）版への適用可能性 を評価するための過程
  • 今回の件は、Rust移行プロセスにおける安定性検証の必要性 を示しており、今後のディストリビューションのセキュリティおよび保守戦略に重要な示唆を与える

Ubuntu 25.10 自動更新障害の概要

  • Ubuntuプロジェクトは、Rustベースのuutilsの date コマンドのバグ により、一部システムが自動で更新を確認できない問題を公式に発表
    • 影響を受けたシステムには、クラウド展開環境、コンテナイメージ、Ubuntu Desktop および Server のインストール環境 が含まれる
    • 自動更新の確認に失敗することで、セキュリティパッチおよびソフトウェア更新が遅延するリスク が存在
  • Ubuntuセキュリティチームは告知を通じて 対処方法（remediation instructions） を提供
    • ユーザーは rust-coreutils パッケージを 0.2.2-0ubuntu2.1 以降に更新 することで問題を解決できる
    • このバグは 自動更新プロセスにのみ影響 し、apt コマンドやその他の手動更新ツールには影響しない

バグの原因と影響範囲

  • 問題の原因は、Rustで再実装されたcoreutils（uutils） の date コマンドが システム時刻の処理過程でエラーを起こしたこと にあると分析されている
    • これにより自動更新スケジューラが 正確な日付計算に失敗 し、更新確認ルーチンが停止した
  • 影響範囲は Ubuntu 25.10 の すべての配布形態 に及び、特に 自動化されたサーバー環境およびクラウドインスタンス では運用停止の可能性があった
  • Ubuntuは今回の問題を通じて、Rustベースのシステムユーティリティに対する安定性検証手順の強化必要性 を認識

Rustベースのユーティリティ移行（「Oxidize」プロジェクト）

  • Ubuntuは 25.10 リリースで 「oxidize」プロジェクト を推進し、従来のCベースのcoreutilsを Rustベースのuutils に置き換える実験を進めている
    • 同時に sudo コマンドのRust版（sudo-rs） も導入し、セキュリティとメモリ安全性の向上を目指している
  • このプロジェクトは、2026年4月予定の長期サポート（LTS）リリース に Rustベースのユーティリティを含められるかを評価するための試験段階
  • LWNはすでに 2025年3月にこのプロジェクトを取り上げ、Rust導入がLinuxディストリビューションの構造的安定性に与える影響 を分析している

修正版と対応ガイド

  • Ubuntuセキュリティ告知によれば、rust-coreutils 0.2.2-0ubuntu2 以下のバージョン に問題が含まれる
    • 0.2.2-0ubuntu2.1 以降 に更新すればバグは解消される
  • ユーザーは apt update && apt upgrade コマンドで パッケージの手動更新 を実行できる
    • 自動更新機能が復旧するまでは、定期的な手動確認 が推奨される

示唆と今後の見通し

  • 今回の件は、Rust移行過程における初期の不安定さ を示す事例として評価できる
    • メモリ安全性とセキュリティ向上のためのRust導入は、機能面の安定性検証 と並行して進める必要があることを示している
  • Ubuntuの実験は、Linuxディストリビューション全体でのRust採用の流れ を加速させる可能性がある
  • 今後のLTSリリースでRustベースのユーティリティが安定して統合されれば、システムセキュリティおよび保守効率の向上 が期待される

関連記事

1件のコメント

 
GN⁺ 2025-10-25
Hacker Newsの意見

  • こういう形で問題を早期に発見するのは悪くないと思う
    LTSリリース前に片付くなら問題ない

    • 普通のUbuntuユーザーとして、これで本当に大丈夫なのかはよく分からない
      uutils/coreutilsのテスト互換性グラフを見ると、まだ完全ではない
      とくにdateはテスト2件しか通っておらず、3件はスキップ、3件はエラーになっている
      この状態で本番運用対応済みと言うのは難しいと思う
    • 複数のシステムを運用していると、一部の構成要素はあまりに信頼しすぎて、問題が起きても疑いすらしなくなる
      こういうバグは個人ユーザーには些細でも、大規模環境では致命的だ
      今日一日ずっとデバッグして、最終的にシステムが明示的に禁止された場所へデータを送っていたことを突き止めた
      その結果システム全体が止まり、依存していたツールが壊れると本当に管理が難しくなる
      もしRust以外の言語だったら、開発者はとんでもない非難を浴びていただろう
    • 中核ユーティリティが明確な理由もなく書き直し版に置き換えられ、その版があまりに不安定で安定版ディストリビューションの更新すらまともにできないのなら、それを問題ないとは言えない
    • 「こうやってイシューを見つけるんだよ」というのは、まるでMicrosoft流の対応みたいに聞こえる /s

  • 既存のcoreutilsには、それほど改善が必要な問題があったのか気になる

    • おそらくライセンス問題が理由かもしれない。以前のこのコメントでもそう推測されていた
    • OpenBSDメンテナーの立場では、ある言語がシステム言語に適しているか判断するには、coreutilsをその言語で実装してみるのが必須らしい
      関連記事: OpenBSDメーリングリスト
    • CVE-2015-4042のようなセキュリティ問題が理由かもしれない
    • Rustで書かれていないこと自体が問題だったようにも見える。とはいえ、なぜborrow checkerがdateのバグを検出できなかったのかは疑問だ
    • 背景を知りたいなら、Ubuntuの公式記事Carefully but purposefully oxidising Ubuntuを読むとよい

  • uutilsでのパッチへのリンクを見つけたい

    • LWNの記事に説明がある
      中核のバグは、date -r <file>対応が実装されていないのにUbuntuがその版を統合したことだ
      コマンドは-rオプションを黙って無視し、何もしなかった
      関連イシュー: #8621, PR #8630
    • Ubuntuのバグレポートはこちらにある
    • 問題の根本は、Rustへの書き直しプロジェクトそのものの存在だと思う
    • 実際の問題説明が不足しているのは残念だ
      最後のコミット（リンク）はdateのパースをGNUと一致させる修正だったが、別のコメントを見ると原因はそれではないのかもしれない

  • 上位コメントは笑えた — 「次のUbuntuリリース名はGrateful Guinea-Pigになるだろう」と言っていた

  • Ubuntuのchangelogを見ると、バグはdate -r関連だ
    changelogとバグレポート、イシュー、PRを見ると、
    date -rはファイルの更新時刻を出力すべきなのに、Rust版は単に無視していた
    こうした基本動作の欠落は、「安全な代替」をうたうプロジェクトとしては残念だ

    • もしこの版がcoreutils公式テストを通過していたのなら、むしろテストスイートが不完全ということかもしれない
    • それでもバッファオーバーフローはなかった！

  • Ubuntuセキュリティ告知 — 典型例のように見える

  • Ubuntu 25.10は使い物にならないほどだと感じた。非LTS版についてここまで言ったのは初めてだ

    • どの点がそこまで深刻なのか、具体的に説明してもらえるとありがたい

  • 「何十年も検証されてきたC製ユーティリティをRustで書き直すのは長期的にはよいかもしれないが、短期的な問題は予測可能だった」という意見には共感する
    ただ、その「長期的」がどれほど長い期間を意味するのかは気になる
    FOSDEMの発表でuutils開発者が誤ったベンチマークを使って性能が高いと主張していたが、実際にはlocale未対応が理由だった点も問題だった
    関連リンク: FOSDEM発表, スレッド1, スレッド2

    • とはいえ、こうした中核ツールも結局は何度もの書き直しを経てきた成果物だ。そこまで極端に見る必要はない
    • locale処理が追加された後は、むしろ性能が向上したというPhoronix記事もある
    • こうした書き直しの代わりに、同じ労力で形式検証システムを構築していたら、セキュリティ面ではよりよかったかもしれないと思う
    • オープンソースプロジェクトが個人の名声作りの手段として使われることもある
      中核ユーティリティを書き直すのは、ポートフォリオ上かなり大きな利点になるからだ

  • guided state-space explorationやfuzzingの最新技術が気になる
    既存実装があるなら、fuzzerが2つの版の挙動を比較してホワイトボックス検証を行えそうだ

    • こういう場合はproperty testingがよく合いそうだ
      入力空間全体に対するproptestを書くにはかなりの労力が必要だが、CLI引数が安定しているなら十分可能だ
      manページのような資料を基に自動生成することもできる
      Rustではproptestクレートを、CLI差分検証にはPythonのHypothesisを外部呼び出しで使うのがよさそうだ