Odebrany

CVE-2026-81003

opublikowano: 11.09.2026, 22:19

modyfikacja: 11.09.2026, 22:19

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

net/iucv: filtruj ramki w afiucv_hs_rcv() według urządzenia wejściowego

afiucv_hs_rcv() wybiera gniazdo z iucv_sk_list, dopasowując cztery 8-bajtowe
pola nazw w samym nagłówku transportu. Nie przeprowadza się żadnej kontroli w stosunku do
net_device, na którym przybyła ramka.

Może to spowodować, że ramka przychodząca na dowolnym Netdevie zostanie dostarczona do AF_IUCV
gniazdo. Następują trzy problemy.

Po pierwsze, ramka docierająca przez HiperSockets może zostać dostarczona do gniazda
powiązany z klasycznym transportem IUCV z/VM, który ma iucv->hs_dev == NULL.
iucv_sock_bind() przyjmuje klasyczną ścieżkę za każdym razem, gdy żądany jest identyfikator użytkownika
pasuje do iucv_userid, nawet na gościu, który ma również urządzenie HiperSockets
noszących ten sam identyfikator. Gniazdo podrzędne utworzone przez
afiucv_hs_callback_syn() dla takiego dopasowania dziedziczy hs_dev = NULL i
transport = AF_IUCV_TRANS_HIPER, więc pierwsza funkcja send() zwraca -ENODEV.
Gniazdo dostarczone do Accept() jest bezużyteczne.

Po drugie, ramka przychodząca na jednego netdeva może zostać dostarczona do gniazda
do innego urządzenia IQD. Do czego może prowadzić
- Wyczerpanie kolejki akceptacji (DoS)
- Tożsamość równorzędna kontrolowana przez atakującego w gnieździe podrzędnym
- Wstrzykiwanie danych do istniejących gniazd
- Szum tkaniny w tkaninie IQD, do której wysyłane są fałszywe odpowiedzi
- zabijanie nawiązanych połączeń

Po trzecie, wszystkie gniazda AF_IUCV znajdują się w init_net, ponieważ wywołania iucv_sock_alloc()
sk_alloc(&init_net, ...). Ale nawet ramki pojawiające się na urządzeniach Netdev w formacie
przestrzeni nazw można dostarczyć do gniazda IUCV. Zatem proces w
nieuprzywilejowana przestrzeń nazw użytkowników i sieci zawierająca tylko CAP_NET_RAW
funkcja ważna w tej przestrzeni nazw może wysłać surową ramkę ETH_P_AF_IUCV
na swoim własnym urządzeniu lo i dopasować je do gniazd init_net.

Napraw wszystkie trzy, pomijając dowolne gniazdo, którego hs_dev nie pasuje do
urządzenie wejściowe. Klasyczne gniazdo IUCV z/VM ma wartość hs_dev == NULL; wejście
dev nigdy nie ma wartości NULL, więc klasyczne gniazda są automatycznie pomijane. Niezwiązany
Gniazdo HIPER ma również hs_dev == NULL i jest pomijane. Związane gniazdo HIPER
jest osiągalny tylko z dokładnie tego urządzenia IQD, z którym był powiązany. Ponieważ hs_dev
jest zawsze urządzeniem w skanach init_net (iucv_sock_bind().
for_each_netdev_rcu(&init_net, ...) wyłącznie), ramka, której ingres
urządzenie należy do innej przestrzeni nazw, nigdy nie pasuje do żadnego gniazda.

Należy pamiętać, że AF_IUCV przez HiperSockets nie zapewnia pojedynczego połączenia
uwierzytelnianie: bez numerów sekwencyjnych, bez TLS, bez jednorazowego użytku. Cztery pola nazw
identyfikujące połączenie są wymieniane w postaci zwykłego tekstu na udostępnionym
Segment HiperSockets (VCHID). Dowolny host w tym samym segmencie HiperSockets
może sfałszować dowolny typ ramki w stosunku do istniejącego połączenia. To jest
właściwość na poziomie protokołu niezmieniona przez tę poprawkę. Poprawka zmniejsza atak
powierzchni do urządzeń równorzędnych znajdujących się w tym samym segmencie HiperSockets.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve