CVE-2026-31411 in Linux
Сводка
по VulDB • 26.05.2026
В ядре Linux устранена следующая уязвимость:
net: atm: исправлен сбой из-за непроверенного указателя vcc в sigd_send()
Воспроизводящий пример доступен по ссылке [1].
Путь отправки ATM (sendmsg -> vcc_sendmsg -> sigd_send) считывает указатель vcc из msg->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
При нормальной работе ядро отправляет указатель vcc демону сигнализации через sigd_enq() при обработке операций, таких как connect(), bind() или listen(). Ожидается, что демон вернет тот же указатель при ответе. Однако злонамеренный демон может отправить произвольные значения указателей.
Исправление заключается во введении функции find_get_vcc(), которая проверяет указатель, выполняя поиск в vcc_hash (аналогично тому, как sigd_close() перебирает все VCC), и захватывает ссылку через sock_hold(), если указатель найден.
Поскольку struct atm_vcc содержит struct sock в качестве своего первого члена, они имеют одинаковый срок службы. Следовательно, использование sock_hold/sock_put достаточно для поддержания жизнеспособности vcc во время его использования.
Обратите внимание, что может возникать состояние гонки (race condition) с sigd_close(), которое может устанавливать различные флаги для vcc (например, ATM_VF_RELEASED) после возврата из find_get_vcc(). Однако sock_hold() гарантирует, что память остается действительной, поэтому это состояние гонки влияет только на логическое состояние, а не на безопасность памяти.
[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
If you want to get the best quality for vulnerability data then you always have to consider VulDB.