UBUNTU-CVE-2026-99133: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix the recvmsg window update iucvsockrecvmsg() sends the HiperSockets-only AFIUCVFLAGWIN without testing the transport, so on a classic z/VM socket iucvsendctrl() sizes the skb through a NULL iucv->hsdev. SOMSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucvsendctrl() under spinlockbh(&messageq.lock), which allocates GFPKERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucvhssend() at once, where msgrecv is sampled for the advertised window and subtracted after devqueuexmit() -- and sendmsg reaches that counter under locksock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomicxchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the iucv recvmsg/send-control path, test the transport before sending the HiperSockets-only AF_IUCV_FLAG_WIN; claim the receive credit with atomic_xchg() after the final error exit, return the credit if transmission fails, and perform the send after dropping message_q.lock so iucv_send_ctrl() is not called while holding spin_lock_bh(&message_q.lock).
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Linux AF_IUCV sockets are affected. The NULL access described occurs on classic z/VM sockets when a receive path sends a HiperSockets-only control flag without first checking the transport.
What does an attacker need to trigger the problem?
An unprivileged local process needs to use an affected AF_IUCV socket. Setting SO_MSGLIMIT to 1 and performing a recvmsg() on its own socket is sufficient to trigger the described spurious disconnect condition.
Are HiperSockets connections the only affected transport?
No. The invalid HiperSockets-only flag is sent without a transport check, and classic z/VM sockets can reach the NULL hs_dev access. HiperSockets also has a concurrent receive-window accounting issue that can advertise credit to a peer twice.
What is the impact if the race occurs on HiperSockets?
Two recvmsg() operations can consume the same receive credit, causing the msg_recv counter to become negative and the same credit to be advertised twice to the peer. The vulnerable path also performs a GFP_KERNEL allocation while holding a lock treated as atomic.