JVNDB-2026-028068 | |
LinuxのLinux KernelにおけるTime-of-check Time-of-use (TOCTOU) 競合状態の脆弱性 | |
| 概要 | |
Linuxカーネルにおいて、以下の脆弱性が修正されました。 rbd: unmap時のlock_dwork排水における競合状態の解消 rbd_lock_add_request()およびrbd_img_exclusive_lock()の実装方法から、lock_dworkは実際に必要なよりも多く(再)キューイングされる可能性があります。例えば、別のI/O要求のためにrbd_acquire_lock()の実行中に新しいI/O要求が入った場合です。これは想定内であり、rbd_release_lock()がlock_dworkを先回りしてキャンセルすることは通常の動作下で無害です。 より問題となる例はmaybe_kick_acquire()内の以下のコードです。 if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) { dout("%s rbd_dev %p kicking lock_dwork ", func, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); } delayed_work_pending()がtrueを返した直後にlock_dworkがキャンセルされ、その直後にmod_delayed_work()で再度キューイングされることは現実的にあり得ます。これは典型的なTOCTOU(時間的競合)レース条件です。 イメージのアンマップに関しては、rbd_dev_image_unlock()からの戻り以降に自己発生の排他的ロック操作が行われないという暗黙の前提があります。この関数はロックが保持されていれば解除し、その解除は最終的なものと見なされ、lock_dwork(および他の排他的ロックタスクも)は再度キューイングされないと期待されています。しかし、lock_dworkのキャンセルはcancel_tasks_sync()(アンマップ処理の後半)でのみ行われ、さらにそのキャンセルもmaybe_kick_acquire()によって実質的に無効化される可能性があります。これにより、rbd_dev_device_release()やrbd_dev_image_release()が実行されてリソースが解放またはリセットされた後でもrbd_acquire_lock()が実行される恐れがあります。 この結果の一つの失敗モードとして、rbd_post_acquire_action()から呼ばれるrbd_dev_refresh()内でrbd_dev_header_info()が呼ばれた際に rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); が破られる可能性があります。 排他的ロックタスクの排水をやり直し、より健全なセマンティクスを提供し、rbd_dev_image_unlock()周辺の前提条件を満たすようにしました。 | |
| CVSS による深刻度 (CVSS とは?) | |
|
CVSS v3 による深刻度
基本値: 7.8 (重要) [その他]
| |
| 影響を受けるシステム | |
|
| |
Linux | |
|
| |
| 想定される影響 | |
・当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。 | |
| 対策 | |
リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。 | |
| ベンダ情報 | |
|
| |
| CWEによる脆弱性タイプ一覧 CWEとは? | |
|
| |
| 共通脆弱性識別子(CVE) CVEとは? | |
|
| |
| 参考情報 | |
| |
| 更新履歴 | |
|
| 公表日 | 2026/07/19 |
| 登録日 | 2026/08/13 |
| 最終更新日 | 2026/08/13 |



