Linux 電力管理ツール TLP の認証バイパスの脆弱性 CVE-2025-67859 が FIX：競合状態による権限昇格

Linux Battery Utility Vulnerability Allows Authentication Bypass and System Tampering 

2026/01/08 gbhackers — Linux 用の電力管理ツール TLP に、認証バイパスおよびシステム改竄を可能にする深刻な脆弱性 CVE-2025-67859 が発見された。この脆弱性は、TLP バージョン 1.9.0 で導入された電力プロファイル・デーモンに影響を及ぼすものであり、ルート権限で電源プロファイルを管理するための D-Bus API を公開している。

この脆弱性の仕組み

TLP のプロファイル・デーモンはルート権限で実行され、電力プロファイルやログ設定をクライアントが変更できるかどうかを判断するために Polkit を使用する。しかし、このデーモンのバージョン 1.9.0 は、Polkit の非推奨サブジェクト “unix-process” に依存していたことで、認証時に呼び出し元の PID のみを渡していた。

これにより、Polkit が PID を評価する時点で、より権限の高いプロセスによって PID が再利用されるという競合状態が発生する。その結果として、ローカル・ユーザーが認証を回避し、TLP の設定に対する特権的な制御権を取得できてしまう。

この脆弱性 CVE-2025-67859 を悪用する任意のローカルユーザーは、管理者の認証情報を提供することなく、アクティブな電源プロファイルおよびデーモン・ログ設定を変更できてしまう。

この問題を修正するために、TLP 1.9.1 では脆弱なメカニズムが、より安全な D-Bus の “システムバス名” サブジェクトに置き換えられた。これにより、認証は競合が発生しやすい PID ではなく、実際のクライアント接続に直接結び付けられるようになった。

それとは別に、研究者たちが発見したものには、影響は小さいが攻撃対象領域を拡大する複数の関連する脆弱性がある。HoldProfile／ReleaseProfile API は、予測可能な増分整数の Cookie 値を使用しており、他ユーザーが Cookie を推測して自身が作成していないプロファイルの保持を解除できる脆弱性が存在していた。

さらに、ReleaseProfile に非整数の Cookie を渡した場合、未処理の Python 例外が発生し、堅牢性が低下する問題も判明した。加えて、デーモンがプロファイルの保持数を無制限に許可していたことで、ローカルユーザーが内部辞書に任意の文字列を追加し、リソース枯渇によるサービス拒否 (DoS) を引き起こす懸念もあった。

CVE ID Affected component Severity / Notes 
CVE-2025-67859 TLP 1.9.0 profiles daemon High – authentication bypass, local root-controlled daemon. 

アップストリームでは、ランダムで予測不可能な Cookie への変更／型処理の強化／同時プロファイル保持数を 16 に制限することで、これらの問題は対処された。今回の主要な Polkit バイパス脆弱性は CVE-2025-67859 として追跡されているが、その他の脆弱性については、アップストリームの判断により深刻度は Low と評価され、個別の識別子は付与されていない。

この脆弱性を悪用するローカル・ユーザーは、電源ポリシーおよび関連デーモンの動作を改竄できるようになる。その結果、厳密に管理された環境において、パフォーマンス／ログ記録／システム動作に関するセキュリティ上の基準が損なわれる可能性がある。

SUSE セキュリティ・チームによると、これらの問題は協調的な開示プロセスの下で報告されたとのことだ。その後のアップストリーム・パッチは、2025年12月に開発され、2026年1月7日に TLP 1.9.1 としてリリースされている。

ユーザーに対して強く推奨されるのは、ディストリビューション・パッケージを通じて TLP 1.9.1 以降へとアップグレードすることだ。あわせて、D-Bus およびシステム電源管理インターフェイスへのアクセスを、信頼できるローカル・ユーザーのみに制限するなど、適切な制御を行うべきである。

Linux 用の電力管理ツール TLP に脆弱性 CVE-2025-67859 が発見されました。この問題の原因は、再利用されやすい PID (Process ID) のみが認証の仕組みにおいて使用されていたことにあります。それにより、権限をチェックする際に、より高い権限を持つ別のプロセスが同じ番号を再利用できてしまう競合状態が発生します。その結果として、本来は許可されない一般ユーザーであっても、管理者のように設定を書き換えられるという問題が生じていました。