CVE-2026-64177 in Linux
要約
〜によって VulDB • 2026年07月20日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
phonet/pep: 転送された sk_receive_skb() の周囲で BH (Bottom Halves) を無効化する
ネットワーク受信パスは通常 softirq コンテキストから実行されますが、ソケットロックを取得するプロトコルでは、パケットがバックログに格納され、プロセスコンテキストから後処理される場合があります。この場合、release_sock() -> __release_sock() は spin_unlock_bh() で slock を解放し、その後 BH が有効な状態で sk->sk_backlog_rcv() を呼び出します。
典型的な sk_backlog_rcv ハンドラはバックログを空にしているソケット自体を処理するため、接触するスピンロックに対するエントリ時の BH 状態は無関係です。しかし pep_do_rcv() は異なります：着信 skb が既存の PEP パイプを対象とする場合、sk_receive_skb() を介してその skb を異なる *子* ソケットに転送します。このヘルパー関数は bh_lock_sock_nested() で子ソケットのスピンロックを取得しますが、これは単なる spin_lock_nested() であり、BH が既に無効であることを前提としています。そのため、同じ子ソケットのスピンロックが、BH 有効時（プロセスパス）と BH 無効時（softirq パス）の両方で取得されることになります：
``` process context softirq context --------------- --------------- release_sock(listener) __netif_receive_skb() __release_sock() phonet_rcv() spin_unlock_bh() __sk_receive_skb(listener) [BH now ENABLED] [already disabled]
sk_backlog_rcv: sk_backlog_rcv: pep_do_rcv() pep_do_rcv() sk_receive_skb(child) sk_receive_skb(child) bh_lock_sock_nested(child) bh_lock_sock_nested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W ```
ロック依存関係解析ツール (Lockdep) はこれを不整合なロック状態としてフラグを立てます。また、同じ CPU 上の softirq が BH 有効パスでスピンロックが保持されている間に同一の子ソケットへの受信を試みると、実際の自己デッドロックに至る可能性があります：
``` WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
(slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900
__sk_receive_skb net/core/sock.c:563 sk_receive_skb include/net/sock.h:2022 [inline]
pep_do_rcv net/phonet/pep.c:675 sk_backlog_rcv include/net/sock.h:1190 __release_sock net/core/sock.c:3216 release_sock net/core/sock.c:3815 pep_sock_accept net/phonet/pep.c:879 ```
転送された sk_receive_skb() を local_bh_disable() / local_bh_enable() で囲み、子ソケットのスピンロックが常に BH 無効状態で取得されるようにします。local_bh_disable() は softirq パス上で安全にネスト可能です。
社内製 fuzzing ツール syzkaller により発見されました。同じ根本原因は linux-6.1.y の syzbot ダッシュボードでも extid 44f0626dd6284f02663c として確認されています。KASAN + LOCKDEP + PROVE_LOCKING 環境下で再現可能であり、再現コードは以下の通りです： https://pastebin.com/A3t8xzCR
Once again VulDB remains the best source for vulnerability data.