JVNDB-2026-022937 | |
LinuxのLinux Kernelにおける解放済みメモリの使用に関する脆弱性 | |
| 概要 | |
Linuxカーネルにおいて、以下の脆弱性が修正されました。io-wqのio_wq_remove_pending()関数内で、先行エントリがハッシュされているかどうかを適切に確認するように改善されました。io_wq_remove_pending()は、キャンセルされたワークがハッシュバケットの末尾にあった場合にwq->hash_tail[]を修正する必要があります。この際、acct->work_listの先行エントリが同じハッシュ値かどうかは確認しますが、先行エントリがそもそもハッシュされているかどうかを一切確認していませんでした。io_get_work_hash()関数は単にatomic_read(&work->flags) >> IO_WQ_HASH_SHIFTを返すだけであり、ハッシュされていないワークにはハッシュビットが設定されないため、常に0を返してしまいます。そのため、ハッシュされたバケット0のワークが、そのリスト内でハッシュされていないワークを先行エントリとしてキャンセルされると、このチェックが誤って成功し、ハッシュされていないio_kiocbへのポインタがwq->hash_tail[0]に格納されてしまいます。ハッシュされていないワークはio_get_next_work()の高速パスを通じてデキューされ、このパスはhash_tail[]に一切触れないため、古くなったポインタがクリアされません。その結果、ハッシュされていないio_kiocbが完了してreq_cachepに解放された後も、wq->hash_tail[0]はダングリングポインタの状態が続きます。io_wqはタスク毎(tctx->io_wq)に管理されており、ringのオープン/クローズをまたいで存続するため、このダングリングポインタはタスクの生存期間中残り続けます。次に、ハッシュされたバケット0のenqueue処理がio_wq_insert_work()内でこのポインタを逆参照し、その後wq_list_add_after()が解放済みメモリを介して書き込みを行います。本修正では、io_wq_is_hashed()による不足していたチェックを追加し、ハッシュされていない先行ワークが決してhash_tail[]のスロットを継承しないようにしました。 | |
| CVSS による深刻度 (CVSS とは?) | |
|
CVSS v3 による深刻度
基本値: 7.8 (重要) [その他]
| |
| 影響を受けるシステム | |
|
| |
Linux | |
|
| |
| 想定される影響 | |
・当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。 | |
| 対策 | |
リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。 | |
| ベンダ情報 | |
|
| |
| CWEによる脆弱性タイプ一覧 CWEとは? | |
| |
| 共通脆弱性識別子(CVE) CVEとは? | |
|
| |
| 参考情報 | |
| |
| 更新履歴 | |
|
| 公表日 | 2026/06/08 |
| 登録日 | 2026/07/10 |
| 最終更新日 | 2026/07/10 |



