CVE-2026-68397: Patch IBM Z AF_IUCV Use-After-Free

The National Vulnerability Database published the record on August 10, 2026, using kernel.org as its source, and lists fixed releases in the currently maintained kernel lines. The practical result is more limited than the broad “Linux kernel” label suggests: this is an IBM s390-specific AF_IUCV configuration issue, not a vulnerability in ordinary x86 or Arm Linux networking and not an issue for Windows hosts.

The race is between packet receive and socket destruction​

The defect is in

, the receive handler for AF_IUCV traffic carried over HiperSockets. The handler searches

under a read lock to find the destination socket for an arriving frame, then releases that lock before sending the socket pointer to one of several protocol callbacks.

That pattern would be safe only if something else kept the socket alive after the list lookup. It did not. As described in the CVE record, AF_IUCV sockets are not protected by RCU, and

can unlink and release a socket synchronously through

after a concurrent close.

In the vulnerable window, the receiver has a valid pointer when it exits the list lookup but can be holding a pointer to freed memory by the time it enters a callback. The kernel’s own description points to

in the SYN callback as one possible dereference. Other callback paths inspect socket state, queues, shutdown state, and transport-specific data, so the lifetime error is not limited to connection setup.

The correction is deliberately small: acquire an additional socket reference with

while the destination remains protected by the list lock, run the selected callback, then balance that reference with

. That does not change AF_IUCV’s wire protocol or connection behavior. It closes the period in which a close operation could turn a looked-up socket into a dangling pointer.

Code mirrors of the Linux tree confirm the important implementation detail behind the CVE description:

runs from the network receive softirq path. A close in process context and a receive callback on another execution path are therefore able to overlap; this is a real concurrency condition, rather than an error that would require an application to misuse the socket API.

AF_IUCV sharply limits the affected population​

The CVE entry describes affected Linux versions from 3.2 onward, a range that can look alarming in an inventory system. But the affected component is built only when

is enabled, and its Kconfig dependency ties it to the s390 architecture plus either QDIO Layer 3 support or IUCV support.

The Linux Kernel Driver Database identifies

as “AF_IUCV Socket support (S390 - z/VM and HiperSockets transport)” and shows the module name as

. Its stated purpose is communication through z/VM’s Inter-User Communication Vehicle or IBM HiperSockets, an in-memory networking technology used by guests and logical partitions on IBM Z systems.

That distinction changes the remediation priority:

• Windows systems are not affected by this Linux kernel vulnerability, including Windows workstations, Windows Server installations, and conventional Hyper-V deployments.
• Standard Linux systems on x86-64, Arm, and other non-s390 architectures are outside the build-time scope of AF_IUCV.
• IBM Z Linux systems that do not enable or load af_iucv do not expose the vulnerable receive path.
• The systems that matter are s390 or s390x deployments using AF_IUCV sockets over HiperSockets, especially where applications establish and tear down those connections under load.

There is an additional operational nuance: AF_IUCV is broader than the older

virtual network device. An administrator who checks only for

can miss an application directly using AF_IUCV sockets. The relevant question is whether the

module is present and used, not merely whether a legacy IUCV network interface has been configured.

On a running system, checking

for

, reviewing the boot kernel configuration for

, and identifying applications or middleware designed for z/VM IUCV or HiperSockets communication will establish exposure more reliably than a generic OS inventory scan.

Fixed releases are available, but the CVE data needs careful reading​

The NVD record names five stable-tree fixes and identifies the first corrected releases as Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4. Those are the versions administrators should use as the minimum upstream baselines for the maintained branches represented in the advisory.

The version data also marks Linux 3.2 and later as affected by default. That is a source-history statement, not a claim that every distribution kernel from 2012 onward can be exploited in the same way. In practice, downstream vendors backport security fixes, may build AF_IUCV as a module, or may omit the configuration altogether. Conversely, a distribution can report an older upstream version string while already containing the patch.

For that reason, do not use

alone as the final answer. Check the vendor’s kernel changelog or security tracker for CVE-2026-68397, and where the vendor has not yet published an advisory, inspect whether its kernel carries the upstream change that adds the socket reference around the

callback dispatch.

The NVD record currently has no CVSS v4, CVSS v3, or CVSS v2 score, and it does not assign a CWE. It also does not describe a public exploit, affected application set, privilege requirement, or a demonstrated confidentiality or code-execution outcome. That missing information is significant: the published evidence establishes a kernel use-after-free defect, but it does not yet establish a remotely exploitable privilege-escalation chain or a reproducible denial-of-service scenario.

A use-after-free in kernel networking code deserves prompt remediation, particularly in multi-tenant or tightly coupled virtualized environments. But severity should not be invented from the bug class alone. The prerequisite combination here is narrow: AF_IUCV must be compiled and active, HiperSockets traffic must reach the matching receive path, and a socket close must land in the small interval after lookup and before the callback finishes.

Why loading the module changes the risk calculation​

The vulnerable function specifically handles HiperSockets transport frames. AF_IUCV can also serve z/VM IUCV communication, but CVE-2026-68397 concerns the HiperSockets receive side rather than every use of the wider IUCV subsystem.

That means a host with

compiled as a module but never loaded has a smaller immediate exposure than a host actively using it. It also means a blanket decision to disable every IUCV-related component could disrupt legitimate IBM Z guest-to-guest communication without addressing the issue in a measured way.

For environments unable to update immediately, the defensible temporary mitigation is to prevent use of the affected AF_IUCV HiperSockets path where operationally feasible. That may mean unloading

on an unused system, preventing automatic module loading, or disabling the application workload that depends on AF_IUCV until the vendor kernel arrives. Any such step needs change control: on a z/VM estate, IUCV and HiperSockets features may underpin management, middleware, or high-speed inter-guest traffic that is not obvious from the host’s ordinary network interface list.

The permanent remediation remains a reboot into a vendor-supplied kernel containing the upstream fix. Because the vulnerability is in kernel memory lifetime handling, restarting the affected application alone does not remove the vulnerable code from the running kernel.

Patch the small number of systems that actually use it​

CVE-2026-68397 is a useful example of why a CVE’s product field is only the start of triage. “Linux kernel” is technically correct, yet it hides the decision-making detail: this defect lives in an optional AF_IUCV module for IBM Z systems using z/VM or HiperSockets transport.

Administrators should identify s390 and s390x hosts first, determine whether

is enabled or loaded, then verify a corrected vendor kernel against the upstream baselines of 6.6.148, 6.12.101, 6.18.42, 7.1.6, or 7.2-rc4. For every other common Linux deployment—and for Windows fleets—the immediate action is documentation rather than emergency patching.