CVE-2026-68140: Linux on IBM Z AF_IUCV Needs Patching

The NVD published the record on August 10, 2026, using kernel.org’s description and stable-tree references. The official record identifies fixed releases in the currently serviced 6.6, 6.12, 6.18, and 7.1 lines, as well as in Linux 7.2 release candidates. Yet it has no CVSS score, no CWE assignment, and no published exploit analysis. That leaves admins with a patching decision based on code-path exposure rather than a vendor-issued severity label.

A queued notification outlives its connection​

The bug is in the lifecycle of an

, the kernel object representing an IUCV connection path. When AF_IUCV receives notification of an incoming message before userspace has called

, it queues an item on

. Each queued item retains a raw pointer to that connection path.

The failure occurs when the remote peer severs the connection before the local application reads those queued messages. According to the kernel.org vulnerability description carried by NVD,

frees the

but historically left the queued notifications in place. A subsequent

call drains the queue, passes the now-invalid pointer into message handling, and dereferences freed memory.

That is the textbook shape of a use-after-free: one part of the kernel releases an object, while another still believes it owns a valid reference. The fix does not try to preserve messages from a connection that no longer exists. Instead, it removes the queued notifications when the path is severed, eliminating both the stale pointer and a separate memory leak caused by closing sockets with pending queued messages.

The practical consequence is also worth spelling out: applications can lose those undelivered messages after a peer-side sever. But they could not validly consume them after the path had already been destroyed. The patch makes the kernel discard data that has become unrecoverable rather than trying to deliver it through freed state.

The exposure is specific to Linux on IBM Z​

IBM’s AF_IUCV documentation describes the facility as an address family for applications communicating through z/VM IUCV or HiperSockets. The kernel’s

option is available only with the S390 architecture and depends on the IUCV capability or the relevant qeth networking support. Debian’s

manual likewise describes AF_IUCV as a transport for System z applications, including communication between z/VM guests and across logical partitions through HiperSockets.

That sharply narrows the immediate affected population. A conventional x86-64 server, a desktop Linux distribution, and a Windows machine with WSL 2 do not run the S390-only AF_IUCV implementation. Having a Linux kernel version in the affected historical range is therefore insufficient by itself: the system must be IBM Z-based and must have AF_IUCV support built and in use.

The configuration test is more useful than a broad inventory query. Administrators should establish whether

is enabled in the running kernel and whether the

module is loaded or required by a deployed application. A system using ordinary TCP/IP networking on Linux for IBM Z is not automatically exposed merely because IUCV support exists elsewhere in the kernel configuration.

The other boundary is trust. The flaw is reached when a connected peer severs an AF_IUCV path while the local endpoint still has pending message notifications, then the local application reads from that socket. The published record does not say whether maintainers have demonstrated privilege escalation, information disclosure, denial of service, or code execution. It also does not identify a proof of concept or active exploitation. A use-after-free is a serious kernel memory-safety condition, but the record does not justify treating it as a confirmed remotely exploitable vulnerability across all IUCV deployments.

Fixed branches are clear — support coverage is not​

NVD’s affected-version data identifies the vulnerable code as present from Linux 2.6.24 onward and lists these first fixed releases:

• Linux 6.6.148 includes the fix.
• Linux 6.12.101 includes the fix.
• Linux 6.18.42 includes the fix.
• Linux 7.1.6 includes the fix.
• Linux 7.2-rc5 includes the upstream fix.

The Linux Kernel Archives currently lists newer releases in every one of those maintained lines: Linux 6.6.151, 6.12.103, 6.18.44, and 7.1.8 were published on August 9, 2026, while 7.2-rc7 is the latest mainline release candidate. Administrators on those current upstream point releases are therefore beyond the listed fixed versions.

The more consequential detail sits in what kernel.org’s references do not cover. The CVE lists five stable commits, corresponding to the supported 6.6, 6.12, 6.18, 7.1, and upstream lines. It does not identify a backport for Linux 6.1, 5.15, or 5.10, even though the Kernel Archives still list Linux 6.1.182, 5.15.215, and 5.10.264 as maintained long-term releases.

That absence should not be read as proof that every vendor kernel based on those series is vulnerable; enterprise distributions commonly backport security fixes without changing the visible upstream version in a straightforward way. But it does mean an administrator cannot mark an IBM Z AF_IUCV system safe simply because it is running a current 6.1, 5.15, or 5.10 upstream point release. At publication, the CVE’s official fixed-version mapping does not show coverage for those branches.

This is the reporting gap in the initial CVE entry. Kernel.org has documented the bug and stable-tree fixes, but it has not supplied a plain-language support matrix explaining why older maintained LTS branches were omitted or whether fixes are pending. No independent outlet appears to have published additional exploitability or backport reporting yet.

Do not let the missing CVSS score delay the inventory​

NVD’s “N/A” CVSS status means NIST has not yet assessed the vulnerability; it is not an assessment of low risk. The public record also lacks a CWE classification, CPE applicability rules, vendor advisories from Linux distributors, and known-exploitation status. Those omissions are normal for a newly published kernel CVE, but they shift responsibility to platform teams that actually operate the feature.

For a Linux on IBM Z estate, the sensible response is to classify machines by actual AF_IUCV use. Systems that compile the feature out or do not load

are outside this bug’s reachable code path. Systems using z/VM guest-to-guest sockets, IUCV-aware utilities, or HiperSockets applications should be treated as patch candidates, particularly where less-trusted tenants or applications can establish and sever these connections.

Distribution packages deserve more weight than an upstream version string. Red Hat, SUSE, Canonical, Debian, and IBM Linux distributors may issue kernel builds containing backports under their own package versions and advisories. Until those advisories explicitly map CVE-2026-68140 to a package, the cleanest confirmation is to inspect the distributor’s kernel changelog or source package for the AF_IUCV fix rather than relying on

alone.

For teams maintaining custom kernels, the remedy is small and readily auditable: ensure the patch that purges queued

notifications during

is present in

. A partial mitigation would be to disable AF_IUCV where the transport is not needed, but that is an operational trade-off, not a replacement for moving an active deployment to a fixed kernel.

Windows readers can treat this as infrastructure intelligence​

This CVE has little direct relevance to Windows endpoints, Windows Server, Hyper-V hosts, or standard WSL environments. Its relevance on a Windows-focused operations forum is at the infrastructure edge: organizations with IBM Z estates often run mixed Windows, Linux, and mainframe operations, and Windows-based monitoring, automation, or administration systems may depend on Linux on IBM Z services that use IUCV internally.

The patch changes no Windows component and requires no Microsoft update. The action belongs with the Linux on IBM Z owner: identify AF_IUCV users, verify the deployed kernel’s backport status, and move exposed systems to one of the documented fixed lines or a distributor kernel that explicitly carries the correction.

The concrete unresolved item is Linux 6.1, 5.15, and 5.10 support. Until stable maintainers or distribution vendors publish backports for those still-maintained branches, AF_IUCV users on them should treat the absence of a listed fix as an open patch-management problem rather than an all-clear.