CVE-2026-31411 in Linux
要約
〜によって VulDB • 2026年05月26日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
net: atm: sigd_send()におけるvccポインタの未検証によるクラッシュを修正
再現手順は[1]で利用可能です。
ATM送信パス（sendmsg -> vcc_sendmsg -> sigd_send）は、msg->vccからvccポインタを読み取り、検証なしで直接使用します。このポインタはsendmsg()経由でユーザー空間から取得され、任意に偽造可能です：
int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // ATMシグナリングデーモンになる struct msghdr msg = { .msg_iov = &iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef; // 偽造されたvccポインタ sendmsg(fd, &msg, 0); // カーネルが0xdeadbeefをデリファレンス
通常の動作では、カーネルはconnect()、bind()、またはlisten()などの操作を処理する際に、sigd_enq()を介してvccポインタをシグナリングデーモンに送信します。デーモンは応答時に同じポインタを返すことが期待されます。しかし、悪意のあるデーモンは任意のポインタ値を送信できます。
find_get_vcc()を導入してこの問題を修正します。この関数はvcc_hash内を検索することでポインタを検証し（sigd_close()がすべてのVCCを反復処理する方法に類似）、見つかった場合はsock_hold()を介して参照を取得します。
struct atm_vccはstruct sockを最初のメンバとして埋め込んでいるため、両者は同じライフタイムを共有します。したがって、使用中のvccを存続させるためにsock_hold/sock_putを使用するだけで十分です。
sigd_close()との間に競合状態が発生する可能性があることに注意してください。これにより、find_get_vcc()が返った後にvccに様々なフラグ（例：ATM_VF_RELEASED）が設定される可能性があります。しかし、sock_hold()はメモリが有効であることを保証するため、この競合状態は論理状態に影響を与えるのみで、メモリの安全性には影響しません。
[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.