CVE-2026-64004

What it actually does

This is a Linux kernel race condition in the AF_IUCV HIPER socket implementation. A local user able to use AF_IUCV HIPER sockets can race recvmsg() against getsockopt(SO_MSGSIZE). During the race, iucv_sock_close() can set the socket's hs_dev pointer to NULL while the getsockopt(SO_MSGSIZE) path later dereferences iucv->hs_dev->mtu without holding the appropriate socket lock. The likely result is a kernel NULL pointer dereference and oops; on systems configured to panic on oops, this can become a full system crash. The upstream fix serializes the getsockopt() switch with lock_sock()/release_sock(), matching the setsockopt() behavior and preventing the stale NULL dereference.

Why it matters to the business

Successful exploitation can cause instability or denial of service on affected Linux systems, particularly systems using IBM s390/z/VM-related IUCV networking features. Because exploitation is local and requires a user or process with access to the affected socket family, internet-scale remote exploitation is unlikely; however, the operational impact can still be significant on shared hosts, virtualization infrastructure, mainframe Linux guests, or systems where untrusted users can run code. The vulnerability is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so remediation should be prioritized based on exposure to AF_IUCV/HIPER usage and local multi-user risk rather than broad external attack likelihood.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user on a Linux system where AF_IUCV HIPER sockets are available. The attacker creates or interacts with an affected IUCV socket and repeatedly triggers two operations in parallel: one thread calls recvmsg() in a way that can close or tear down the IUCV socket path, while another thread calls getsockopt(SO_MSGSIZE). Without the corrected locking, the recvmsg() path can invoke iucv_sock_close() and clear hs_dev while the getsockopt() path concurrently attempts to read hs_dev->mtu. This causes a NULL pointer dereference in kernel context, generating an oops and potentially crashing the host depending on kernel panic settings.

How to fix it

Apply a Linux kernel update that includes the upstream fix for net/iucv getsockopt() locking. Because no product-specific fixed versions were provided, use the kernel packages from the relevant Linux distribution or vendor advisory and verify that the fix wrapping the IUCV getsockopt() switch in lock_sock()/release_sock() is included. Where immediate patching is not possible, reduce exposure by disabling or unloading unused IUCV/HIPER functionality where operationally safe, restricting local shell access, limiting execution by untrusted users, and reviewing whether AF_IUCV socket creation can be constrained through host hardening controls such as containers, seccomp profiles, LSM policies, or workload isolation. Consider setting appropriate kernel panic-on-oops behavior based on operational requirements, recognizing that changing panic behavior is a risk tradeoff and not a vulnerability fix.

How to confirm the fix worked

Confirm the running kernel version is at or above the distribution's fixed build for this issue, not merely that an updated package is installed. Reboot into the patched kernel if required. Validate exposure by checking whether IUCV support is present, whether relevant modules are loaded, and whether the system platform or workloads use AF_IUCV/HIPER communication. On source-built kernels, confirm the net/iucv getsockopt implementation holds the socket lock across the SO_MSGSIZE path and no longer relies only on the earlier SO_MSGLIMIT-specific lock. After remediation, monitor kernel logs for absence of new NULL pointer dereference/oops events involving IUCV socket functions under normal workload or controlled regression testing.

Typical attack path

1. Gain local shell or ability to execute code on an affected Linux host.
2. Confirm AF_IUCV/HIPER socket support is present and usable.
3. Create an AF_IUCV socket and prepare concurrent socket operations.
4. Run one execution thread repeatedly invoking recvmsg() to drive socket close/teardown behavior.
5. Run another execution thread repeatedly invoking getsockopt(SO_MSGSIZE) against the same socket state.
6. Win the race so hs_dev is set to NULL before the SO_MSGSIZE getsockopt path dereferences hs_dev->mtu.
7. Trigger a kernel oops or panic, causing service disruption or host crash.

How to detect it

To determine whether exploitation has already occurred, review kernel logs, system journal entries, hypervisor/guest console logs, crash dump records, and monitoring alerts for kernel oops or panic events involving the IUCV networking stack. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel logs, kdump/vmcore metadata, crash reporting systems, and uptime/reboot telemetry. Look for NULL pointer dereference messages, call traces that include IUCV socket functions, and events temporally associated with local user activity or suspicious processes repeatedly invoking socket operations. Because this issue produces a kernel fault rather than a stable userland artifact, detection is primarily based on crash/oops evidence, unexpected reboots, and kernel call traces rather than files left behind. Correlate any observed crashes with local login, process execution, container workload activity, or abnormal development/test binaries running shortly before the event.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• iucv_sock_getsockopt
• iucv_sock_close
• iucv_sock_recvmsg
• iucv->hs_dev->mtu
• SO_MSGSIZE
• AF_IUCV
• net/iucv
• IUCV

What your security team should do

• Prioritize patching affected Linux kernels on s390/z/VM, mainframe Linux guests, shared compute platforms, and any systems where AF_IUCV/HIPER sockets are enabled.
• Inventory systems with IUCV support enabled or IUCV-related modules loaded; deprioritize systems where the feature is not present or not reachable by local users.
• Restrict local interactive access and arbitrary code execution on exposed systems until patched.
• For containerized or multi-tenant workloads, review seccomp, LSM, and runtime policies to limit unnecessary socket families and kernel attack surface.
• Monitor kernel logs and crash dumps for NULL pointer dereferences or oops traces involving iucv socket functions.
• Ensure patched kernel packages are installed and systems have rebooted into the fixed kernel.
• Because there is no known KEV listing, ransomware association, or public exploit maturity in the provided data, treat this as a local stability and privilege-bound denial-of-service risk rather than an active mass-exploitation emergency.