PT-2026-128126

CVE-2026-99133

·

Published

2026-10-28

·

Updated

2026-10-28

Description by

Score
N/A
Not available

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.

In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix the recvmsg window update
iucv sock recvmsg() sends the HiperSockets-only AF IUCV FLAG WIN without testing the transport, so on a classic z/VM socket iucv send ctrl() sizes the skb through a NULL iucv->hs dev. SO MSGLIMIT 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 iucv send ctrl() under spin lock bh(&message q.lock), which allocates GFP KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv hs send() at once, where msg recv is sampled for the advertised window and subtracted after dev queue xmit() -- and sendmsg reaches that counter under lock sock() 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 atomic xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped.
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾