---
id: "CVE-2026-99133"
kind: "vulnerability"
aliases: ["CVE-2026-99133"]
title: "Linux kernel: IUCV recvmsg window update crashes z/VM sockets"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["ibm-z", "iucv", "linux-kernel", "other", "z-vm"]
not_affected_if: ["no-af-iucv-sockets", "non-s390"]
published_at: "2026-10-28T11:17:33+00:00"
first_seen_at: "2026-10-28T11:32:35+00:00"
updated_at: "2026-10-28T11:36:14+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99133", "first_seen_at": "2026-10-28T11:32:35+00:00"}]
---

# Linux kernel: IUCV recvmsg window update crashes z/VM sockets

On classic z/VM AF_IUCV sockets, a recvmsg() window update dereferences a NULL HiperSockets device, and a race can double-send flow-control credit. An unprivileged local process can trigger a spurious disconnect, and the sources do not say whether memory corruption or code execution is possible.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- unknown

## Timeline

- 2026-10-28T11:32:35+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99133

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_