CVE-2026-68141

What it actually does

CVE-2026-68141 is a Linux kernel denial-of-service flaw in the AF_IUCV networking code, specifically afiucv_hs_callback_syn(). When the kernel attempts to allocate a child socket with GFP_ATOMIC and that allocation fails, the resulting socket pointer is NULL. The error-handling path can then call iucv_sock_kill() with that NULL pointer, causing an immediate NULL pointer dereference in kernel context. The likely result is a kernel oops or panic, depending on system configuration, availability of AF_IUCV, and panic-on-oops behavior. This affects systems using or exposing the Linux IUCV socket functionality, primarily relevant to IBM Z/s390 environments where IUCV is used.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt workloads that depend on them. For organizations running Linux on IBM Z/s390 or using AF_IUCV-based communication, this could cause service outages, interrupted batch processing, failed inter-VM communication, and operational instability. The vulnerability is recently published, is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and is not identified as ransomware-used, so urgency should be driven by whether AF_IUCV is enabled or used in production and whether kernel crashes would affect critical services.

How an attack unfolds

An attacker needs a way to trigger AF_IUCV connection handling on an affected Linux system. They induce conditions where afiucv_hs_callback_syn() enters its connection-refused handling path, such as when the listener is not in the expected state, the accept backlog is full, or child socket allocation fails under memory pressure. The most security-relevant path is forcing or coinciding with GFP_ATOMIC allocation failure, leaving nsk as NULL. The vulnerable code then calls iucv_sock_kill(nsk) without checking whether nsk was allocated. Because iucv_sock_kill() dereferences the socket pointer immediately, the kernel dereferences NULL and may oops or panic, causing denial of service. Practical exploitability depends heavily on AF_IUCV reachability, local or adjacent access to IUCV communication paths, and the ability to influence connection volume or memory pressure.

How to fix it

Apply a Linux kernel update that includes the upstream fix for AF_IUCV afiucv_hs_callback_syn(), which changes the error path to call iucv_sock_kill() only when a child socket was successfully allocated. Because no product-specific fixed versions were supplied, track the advisory stream for the relevant Linux distribution or kernel vendor and upgrade to the first kernel build containing the fix for CVE-2026-68141. If immediate patching is not possible, reduce exposure by disabling or unloading AF_IUCV where it is not required, restricting access to IUCV communication paths, reducing untrusted connection sources, monitoring for backlog exhaustion or memory pressure, and configuring operational safeguards for kernel crash recovery. Evaluate panic-on-oops settings carefully: disabling panic-on-oops may reduce full-system reboots but can leave systems in an unreliable state after a kernel fault; follow vendor guidance.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed build containing the AF_IUCV NULL pointer dereference fix. Validate that the patched source or binary includes the logic preventing iucv_sock_kill() from being called when nsk is NULL in afiucv_hs_callback_syn(). Check whether AF_IUCV is enabled by reviewing loaded modules, kernel configuration, and use of AF_IUCV sockets on the system. After patching, reboot into the fixed kernel and verify with uname, package manager queries, and distribution advisory metadata. For exposure validation, determine whether the system is an IBM Z/s390 Linux environment or otherwise has IUCV support active, and whether any services rely on AF_IUCV communication.

Typical attack path

1. Identify a Linux system using a vulnerable kernel with AF_IUCV support enabled or loaded.
2. Gain the ability to initiate or influence IUCV socket connection attempts to the target service or communication endpoint.
3. Generate connection attempts that cause the listener to reject connections, fill the accept backlog, or coincide with low-memory/GFP_ATOMIC allocation failure conditions.
4. Trigger afiucv_hs_callback_syn() to enter the connection-refused path with a NULL child socket pointer.
5. Cause iucv_sock_kill() to dereference the NULL pointer in kernel context.
6. Result in a kernel oops or panic, disrupting the affected host or dependent workloads.

How to detect it

Look for signs of attempted or successful denial of service rather than post-compromise artifacts, because this flaw causes a kernel NULL pointer dereference and does not provide code execution. Relevant sources include kernel ring buffer output, system logs, crash dumps, kdump/vmcore artifacts, journald, console logs, hypervisor or mainframe operational logs, and monitoring alerts for sudden host reboot or kernel panic. Search for kernel oops or panic messages mentioning AF_IUCV, IUCV socket handling, afiucv_hs_callback_syn(), iucv_sock_kill(), NULL pointer dereference, or general protection/oops traces around network/IUCV activity. Correlate crashes with spikes in IUCV connection attempts, accept backlog exhaustion, low-memory or allocation failure messages, and service restarts. If crash dumps are available, inspect stack traces for afiucv_hs_callback_syn calling iucv_sock_kill with a NULL socket pointer. There are no known threat actors or ransomware campaigns in the supplied data, so detection should focus on reliability anomalies and crash forensics rather than actor-specific indicators.

• afiucv_hs_callback_syn
• iucv_sock_kill
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• Call Trace:
• AF_IUCV
• af_iucv
• iucv
• GFP_ATOMIC
• allocation failure
• accept backlog

What your security team should do

• Prioritize patching on Linux systems running on IBM Z/s390 or any host where AF_IUCV/IUCV sockets are enabled or business-critical.
• Inventory kernels and distribution builds to identify systems that include vulnerable AF_IUCV code and confirm whether vendor-fixed packages are available.
• If AF_IUCV is not required, disable or prevent loading of the relevant kernel functionality as a temporary mitigation.
• Monitor kernel logs for NULL pointer dereference, oops, panic, or call traces involving afiucv_hs_callback_syn and iucv_sock_kill.
• Review availability requirements for affected hosts and ensure clustering, failover, watchdog, and crash-recovery procedures are functioning.
• Because the issue is newly published and not currently in KEV, continue monitoring vendor advisories, exploit repositories, and threat intelligence for changes in exploit maturity.