CVE-2026-68140

What it actually does

This is a use-after-free flaw in the Linux kernel AF_IUCV networking code, primarily relevant to IBM Z / s390 environments using IUCV communication. AF_IUCV queues pending message notifications that contain raw pointers to an iucv_path object. When a peer severs the IUCV connection, the kernel frees that path, but the queued notifications can remain. A later recvmsg() call drains the queue and passes the stale pointer into message handling, causing the kernel to dereference freed memory. The likely outcomes are kernel memory corruption and denial of service through a kernel crash; depending on allocator state, kernel configuration, and exploit development, privilege escalation or code execution in kernel context may be theoretically possible but no public exploit maturity is currently indicated.

Why it matters to the business

Systems that rely on Linux AF_IUCV communication could be crashed by a malicious or compromised IUCV peer or workload, causing service interruption on affected hosts. The highest operational concern is availability for IBM Z / s390 Linux workloads that use IUCV-based communication channels. Because this issue is newly published, not currently listed in CISA KEV, and has no reported exploit maturity, immediate emergency response is less likely to be required than for actively exploited flaws; however, kernel memory corruption bugs should still be prioritized for scheduled patching, especially on multi-tenant or high-availability systems.

How an attack unfolds

An attacker needs a position where they can interact with an affected AF_IUCV socket path, such as a malicious peer, compromised local workload, or other entity able to trigger IUCV message exchange and connection teardown. The attacker causes message notifications to be queued for an AF_IUCV connection and then severs the IUCV path before those queued notifications are received. The vulnerable kernel frees the iucv_path object but leaves queued notifications pointing to it. When the receiving process later calls recvmsg(), the kernel processes the pending message queue and dereferences the stale pointer. This can trigger a kernel oops, panic, or other memory corruption condition. Reliable exploitation beyond denial of service would require controlling timing and heap reuse and is not indicated as publicly available from the provided intelligence.

How to fix it

Apply the Linux kernel update from the relevant distribution or appliance vendor that includes the upstream fix for net/iucv: dropping queued AF_IUCV notifications when an IUCV path is severed. Because no product-specific fixed versions were provided, use vendor advisories and package changelogs to identify the first kernel build containing the fix for CVE-2026-68140 or the corresponding upstream commit titled "net/iucv: fix use-after-free of a severed iucv_path." Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly covers this AF_IUCV fix. If AF_IUCV/IUCV functionality is not required, reduce exposure by disabling or not loading the AF_IUCV module where supported, building kernels without CONFIG_AF_IUCV, and limiting workloads or users that can create/use AF_IUCV sockets. Treat mitigations as temporary because the robust fix is the kernel patch.

How to confirm the fix worked

Confirm exposure by checking whether the host is an s390/IBM Z Linux system with AF_IUCV support enabled or loaded, for example by reviewing kernel configuration for CONFIG_AF_IUCV and loaded modules for af_iucv. Confirm remediation by verifying the running kernel version matches a vendor-fixed build and that the vendor changelog references CVE-2026-68140 or the upstream fix for "net/iucv: fix use-after-free of a severed iucv_path." Ensure the system has rebooted into the patched kernel, not merely installed it. Where source or debug packages are available, validate that the AF_IUCV sever-path handling drops queued message notifications before freeing the path. For mitigation validation, confirm AF_IUCV is not loaded or available if the feature is not required.

Typical attack path

1. Identify a Linux system running on an affected s390/IBM Z kernel with AF_IUCV support enabled and in use.
2. Gain the ability to communicate as, or influence, an IUCV peer or local workload using AF_IUCV sockets.
3. Send or trigger IUCV messages so that AF_IUCV message notifications are queued but not yet received.
4. Sever the IUCV path before the receiving application drains the message queue.
5. Cause or wait for the receiving process to call recvmsg() on the affected socket.
6. Trigger dereference of the freed iucv_path pointer, causing kernel memory corruption, usually observed as a kernel oops or crash.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel and system logs rather than network perimeter logs, because the failure occurs inside Linux kernel AF_IUCV handling. Review dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, and KASAN/KMSAN reports for use-after-free, kernel oops, panic, slab corruption, or general protection fault entries involving AF_IUCV or IUCV functions. Pay particular attention to crashes occurring shortly after IUCV connection severing, AF_IUCV recvmsg activity, or repeated application failures using IUCV sockets. If kernel crash dumps are available, inspect stack traces for iucv_process_message_q(), message_receive(), iucv_sever_path(), iucv_path_free(), or af_iucv recv paths. Correlate events with processes known to use AF_IUCV sockets and with any unexpected workload, peer, or guest initiating IUCV communication. There are no reliable remote network IOCs for this vulnerability from the provided information; detection is primarily host-based crash and kernel telemetry analysis.

• af_iucv
• iucv_process_message_q
• message_receive
• iucv_sever_path
• iucv_path_free
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• Oops
• Kernel panic
• recvmsg
• CONFIG_AF_IUCV
• net/iucv

What your security team should do

• Inventory Linux systems running on s390/IBM Z and identify those with AF_IUCV/IUCV enabled or in use.
• Prioritize patching affected kernels on systems that host untrusted workloads, multi-tenant services, high-availability applications, or externally influenced IUCV communication paths.
• Apply vendor kernel updates and reboot into the fixed kernel; track completion separately from package installation.
• If patching must be delayed, disable AF_IUCV/IUCV where it is not business-critical and restrict workloads that can use IUCV communication.
• Monitor kernel logs for AF_IUCV-related crashes, KASAN use-after-free reports, general protection faults, kernel oops messages, or panics involving iucv_process_message_q, message_receive, iucv_sever_path, or iucv_path_free.
• Because this is not currently in CISA KEV and no exploit maturity is reported, handle as high-priority kernel maintenance rather than confirmed active exploitation unless local telemetry shows matching crash artifacts.