CVE-2026-99126 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/ctcm: Prevent XID null dereference
The mpc_validate_xid() function sets grp->saved_xid2->xid2_flag2 to 0x40 to signal XID validation error. If peer XID is NULL or r/w channel pairing mismatch happens, grp->saved_xid2 is never initialized. An attempt to set the flag in such case leads to NULL dereference.
Fix this by using the always available priv->xid->xid2_flag2 instead of grp->saved_xid2->xid2_flag2 for validation errors.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified as a null pointer dereference within the Linux kernel's s390 channel-to-channel (ctcm) driver presents a significant stability risk, particularly in environments relying on high-performance mainframe interconnects. The core of this issue resides in the mpc_validate_xid function, which is responsible for validating Exchange Identification data during communication setup between peers. Under normal operational conditions, the system initializes a structure member named grp->saved_xid2 to store validated identification information. However, specific edge cases involving null peer XID values or mismatches in read-write channel pairing prevent this initialization from occurring. When such an error condition is detected later in the validation flow, the code attempts to set the xid2_flag2 field of the uninitialized grp->saved_xid2 structure to 0x40 to signal a validation failure. Because the pointer was never allocated or assigned due to the earlier mismatch or null state, this write operation targets an invalid memory address, resulting in a kernel NULL pointer dereference that typically causes a system crash or panic.
From a technical perspective, this flaw represents a classic use-after-free or uninitialized variable access pattern, specifically categorized under CWE-476 which denotes a NULL Pointer Dereference. The root cause is not merely a lack of bounds checking but rather a logical gap in the error handling path where the code assumes that certain data structures are always present and initialized before attempting to modify their fields for status reporting. In the context of the ATT&CK framework, this vulnerability aligns with techniques related to Denial of Service via system crashes or kernel panics, which can be exploited by a local attacker who has access to network interfaces configured in specific ways that trigger these channel pairing mismatches. The impact is primarily availability-related, as the resulting kernel panic renders the affected host unusable until it is rebooted, disrupting services dependent on s390 ctcm connectivity.
The resolution involves refactoring the error handling logic within mpc_validate_xid to avoid accessing the potentially uninitialized grp->saved_xid2 structure entirely. Instead of attempting to write to a pointer that may be null, the fix redirects the flag setting operation to use priv->xid->xid2_flag2. This alternative field is guaranteed to be available and properly initialized throughout the lifecycle of the connection setup process because it resides within the primary private data structure associated with the channel interface. By leveraging this always-available memory location for signaling validation errors, the code eliminates the risk of dereferencing a null pointer while maintaining the intended functionality of flagging XID validation failures to higher-level protocol handlers.
To mitigate similar vulnerabilities in kernel development and ensure robust security posture, developers should enforce strict initialization checks before accessing any dynamically allocated or conditionally initialized structures. Implementing defensive programming practices where every potential path that leads to an error state explicitly validates pointer validity is crucial. Furthermore, static analysis tools configured with rules for CWE-476 can help identify such uninitialized variable accesses during the code review phase. For system administrators managing s390 environments, applying this kernel patch promptly is essential to maintain service continuity and prevent potential denial-of-service conditions arising from malformed or mismatched channel configurations. Regular updates of the Linux kernel ensure that these low-level driver flaws are addressed before they can be triggered in production workloads.