JVNDB-2026-012704 | |
LinuxのLinux Kernelにおける競合状態に関する脆弱性 | |
| 概要 | |
Linuxカーネルにおいて、以下の脆弱性が修正されました。af_unixにおいて、MSG_PEEKが介入した場合にガベージコレクション(GC)をあきらめる問題です。Igor Ushakov氏は、MSG_PEEKとの競合により生存しているソケットの受信キューがGCによって消去される問題を報告しました。この問題は、以前のコミットcbcf01128d0a("af_unix: fix garbage collect vs MSG_PEEK")で修正されたのとまったく同じ問題でした。GCが現在のアルゴリズムに置き換えられた後、このコミットはunix_peek_fds()内のロック調整を除去し、同じ問題を再導入しました。問題の原因は、MSG_PEEKがGCと連動せずにファイル参照カウントを増加させてしまうことです。sk-Aとsk-Bを含む強連結成分(SCC)を考えます。sk-Aはclose()されているがsk-B経由でrecv()が可能です。悪影響は、sk-BからMSG_PEEK付きでsk-Aがrecv()され、GCがsk-Aとsk-Bのunix_vertex_dead()をチェックしている間にsk-Bがclose()された場合に発生します。GCスレッドはunix_vertex_dead(sk-A)をtrueと判断しますが、recv(sk-B, MSG_PEEK)によりsk-Aのファイル参照カウントが1から2に増えます。次にclose(sk-B)が呼ばれ、sk-Bのファイル参照カウントが2から1になります。最初はsk-Aのファイル参照カウントはsk-Bのrecvキューにあるファイルディスクリプタによって1でした。GCはファイル参照カウントがインフライトのファイルディスクリプタ数と同じためsk-Aは死んでいると考えます。しかしMSG_PEEKによりsk-Aのファイル参照カウントが密かに増加し、GCの評価が無効になります。この時点でsk-Bのファイル参照カウントはオープンファイルディスクリプタによる1とsk-A内のインフライトファイルディスクリプタによる1の計2です。その後のclose()で1つの参照が解放されます。結果としてGCはsk-Aとsk-Bの両方が死んでいると誤判断します。一つの対策はunix_peek_fds()でロック調整を復元することですが、新しいアルゴリズムを活用し、よりエレガントに解決可能です。問題は次にclose()が発生しなければ起きず、MSG_PEEKと死んだSCC検出を同期させる必要は実際にはありません。問題発生時にclose()とGCが同じファイル参照カウントに触れます。GCがclose()による参照カウントの減少を検知すれば、SCCのガベージコレクトをあきらめるだけで済みます。したがってMSG_PEEK中の競合を正しいメモリバリアでGCに可視化するだけで十分です。seqcount_tを使いMSG_PEEK発生をGCに通知し、次の実行でSCCの処理を延期させます。これによりMSG_PEEK側にロックは不要となり、不要なペナルティを避けられます。なおunix_scc_dead()内でMSG_PEEK検出時にリトライ可能ですが、濫用によるタスクハングを避けるため、実行しません。 | |
| CVSS による深刻度 (CVSS とは?) | |
|
CVSS v3 による深刻度
基本値: 4.7 (警告) [NVD値]
| |
| 影響を受けるシステム | |
|
| |
Linux | |
|
| |
| 想定される影響 | |
当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 | |
| 対策 | |
リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。 | |
| ベンダ情報 | |
|
| |
| CWEによる脆弱性タイプ一覧 CWEとは? | |
| |
| 共通脆弱性識別子(CVE) CVEとは? | |
|
| |
| 参考情報 | |
| |
| 更新履歴 | |
|
| 公表日 | 2026/03/25 |
| 登録日 | 2026/04/27 |
| 最終更新日 | 2026/04/27 |



