CVE-2026-81003 Linux — эксплойт и детали уязвимости HIGH

Параметр	Значение
CVSS	8,1 (HIGH)
Поставщик	Linux
Публичный эксплойт	Нет

В ядре Linux устранена следующая уязвимость: net/iucv: фильтровать кадры в afiucv_hs_rcv() по входному устройству afiucv_hs_rcv() выбирает сокет из iucv_sk_list, сопоставляя четыре 8-байтовых поля имени только в заголовке транспорта. Никакая проверка не производится по net_device, на которое прибыл кадр. Это может привести к тому, что кадр, поступающий на любое сетевое устройство, будет доставлен в AF_IUCV. розетка.

Далее следуют три проблемы. Во-первых, кадр, поступающий через HiperSockets, может быть доставлен в сокет. привязан к классическому транспорту z/VM IUCV, который имеет iucv->hs_dev == NULL. iucv_sock_bind() использует классический путь всякий раз, когда запрошенный идентификатор пользователя соответствует iucv_userid даже для гостя, у которого также есть устройство HiperSockets несущий тот же идентификатор. Дочерний сокет, созданный afiucv_hs_callback_syn() для такого совпадения наследует hs_dev = NULL и транспорт = AF_IUCV_TRANS_HIPER, поэтому первая функция send() возвращает -ENODEV.

Сокет, доставленный в метод Accept(), непригоден для использования. Во-вторых, кадр, поступающий на один сетевой дев, может быть доставлен в связанный сокет. на другое устройство IQD. Что может привести к - Исчерпание очереди приема (DoS) - Контролируемая злоумышленником идентификация однорангового узла в дочернем сокете - Внедрение данных в существующие сокеты - Шум в фабрике IQD, куда отправляются фиктивные ответы. - уничтожение установленных связей В-третьих, все сокеты AF_IUCV находятся в init_net, поскольку вызывается iucv_sock_alloc(). sk_alloc(&init_net, ...).

Но даже кадры, поступающие на устройства netdev в пространство имен может быть доставлено в сокет IUCV. Таким образом, процесс в непривилегированное пользовательское и сетевое пространство имен, содержащее только CAP_NET_RAW возможность, действительная в этом пространстве имен, может отправлять необработанный кадр ETH_P_AF_IUCV на своем собственном устройстве lo и сопоставить его с сокетами init_net. Исправьте все три, пропуская любой сокет, hs_dev которого не соответствует входное устройство.

Классический сокет z/VM IUCV имеет hs_dev == NULL; вход dev никогда не имеет значения NULL, поэтому классические сокеты автоматически пропускаются. Несвязанный Сокет HIPER также имеет hs_dev == NULL и пропускается. Связанный сокет HIPER доступен только с того устройства IQD, к которому он был привязан.

Потому что hs_dev всегда является устройством в init_net (iucv_sock_bind() сканирует for_each_netdev_rcu(&init_net, ...) исключительно), кадр, вход которого устройство принадлежит другому пространству имен и никогда не соответствует ни одному сокету. Обратите внимание, что AF_IUCV через HiperSockets не обеспечивает отдельное соединение. аутентификация: без порядковых номеров, без TLS, без nonce. Четыре поля имени идентифицирующие соединение, передаются в виде открытого текста на общем Сегмент HiperSockets (VCHID).

Любой хост в том же сегменте HiperSockets. может подделать любой тип кадра в отношении существующего соединения. Это Свойство уровня протокола не изменено этим патчем. Исправление уменьшает атаку доступ к узлам, присутствующим в том же сегменте HiperSockets.

Показать оригинальное описание (EN)

In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.