Cloudanix VulnDB

CVE-2026-99133

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel networking code for certain mainframe sockets lets an ordinary program cause unexpected disconnections or crashes.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in AF_IUCV recvmsg handling that dereferences a NULL hs_dev pointer on non-HiperSockets transports and allows concurrent window credit subtraction without proper locking or atomic protection, enabling negative credits and spurious disconnects.

Why it matters to the business

Unprivileged local processes can trigger kernel-level disconnects or crashes on systems using z/VM IUCV sockets, leading to service interruption and requiring kernel updates for affected Linux distributions.

How an attack unfolds

An unprivileged process sets a minimal message limit on an AF_IUCV socket, then issues recvmsg calls that either hit the untested transport path causing a NULL dereference or race with another recvmsg to double-subtract window credit, forcing a disconnect or invalid state visible to the peer.

How to fix it

Apply the upstream fix that tests the transport before sending WIN flags, moves iucv_send_ctrl outside the spinlock, uses atomic_xchg for credit, and returns credit on transmit failure; rebuild and reboot to the patched kernel.

How to confirm the fix worked

Verify the running kernel contains the commit that adds the transport test and atomic credit handling in iucv_sock_recvmsg; confirm no GFP_KERNEL allocations remain under spin_lock_bh in that function.

Typical attack path

  1. Create AF_IUCV socket and set SO_MSGLIMIT to 1 via setsockopt
  2. Issue recvmsg on the socket to trigger either the missing transport test or the locked send path
  3. Trigger concurrent recvmsg from another thread to race the credit counter
  4. Observe kernel panic, socket disconnect, or peer receiving duplicate credit

How to detect it

Search kernel logs for oops or warnings mentioning iucv_sock_recvmsg, NULL hs_dev, or message_q.lock; inspect audit logs for unusual setsockopt SO_MSGLIMIT calls followed by rapid socket closures on IUCV-using processes.

  • iucv_sock_recvmsg
  • NULL iucv->hs_dev
  • spin_lock_bh(&message_q.lock)
  • GFP_KERNEL inside atomic section
  • msglimit / 2 is zero

What your security team should do

  • Prioritize kernel updates on any system exposing AF_IUCV sockets within 48 hours
  • Restrict unprivileged access to AF_IUCV socket creation via LSM or seccomp until patched
  • Monitor for rapid socket disconnects or kernel oops involving iucv in production workloads

The record

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.

Affected packages

Ecosystem Package Introduced Fixed