CVE-2026-98476 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()
The channel path registry entry associated with a CHPID may be removed while the subchannel's PMCW still references that CHPID. In this case, chpid_to_chp() can return NULL, leading to a NULL pointer dereference.
Add the missing NULL check before dereferencing the returned pointer.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel involves a critical null pointer dereception within the s390 channel I/O subsystem, specifically affecting the ccw_device_get_util_str function. This issue arises from an inconsistency between the state of the subchannel's PMCW (Programmed Control Word) and the availability of its associated channel path registry entry. In IBM mainframe architectures utilizing the Linux kernel on s390 hardware, devices are managed through a complex hierarchy involving CHPIDs (Channel Path IDs), subchannels, and device drivers. The system maintains a registry mapping these identifiers to ensure proper resource management and status reporting. However, under certain race conditions or timing scenarios, it is possible for the channel path registry entry corresponding to a specific CHPID to be removed from memory while the subchannel's PMCW still retains a reference to that same CHPID. This temporal mismatch creates a dangerous state where subsequent operations attempting to resolve the physical channel path based on the stored identifier will fail to find the expected data structure.
The technical root cause lies in the chpid_to_chp function, which is responsible for translating a Channel Path ID into its corresponding internal representation within the kernel's device model. When this function encounters a CHPID that no longer has an associated registry entry due to prior removal or unregistration, it returns NULL instead of a valid pointer. The vulnerable code path in ccw_device_get_util_str fails to validate this return value before attempting to dereference it for utility string generation purposes. This lack of defensive programming leads directly to a kernel panic or system crash when the null address is accessed. Such an event disrupts the stability of the host operating system, potentially causing unplanned downtime for critical mainframe workloads that rely on continuous availability and high reliability standards typical of s390 environments.
From a security perspective, this vulnerability represents a denial-of-service condition resulting from improper input validation or state management within kernel-space code. It aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities where software fails to check for null pointers before using them as valid addresses. In the context of the MITRE ATT&CK framework, this flaw could be leveraged by an attacker who can influence device attachment or detachment sequences, potentially triggering the race condition remotely if they have access to manage channel paths via management interfaces like HMC (Hardware Management Console) APIs exposed through virtualization layers. Although direct exploitation typically requires privileged access to manipulate hardware configuration, the resulting system crash impacts availability, a core pillar of information security integrity models.
The operational impact includes immediate service interruption for any workload utilizing affected devices during the window where the registry entry is missing but the PMCW reference persists. For enterprise environments running mission-critical applications on z/VM or Linux on Z, such instability can lead to significant financial and reputational damage due to SLA violations. Mitigation strategies primarily involve applying the vendor-provided kernel patch that introduces a null check before dereferencing the pointer returned by chpid_to_chp. Administrators should ensure their systems are updated with the latest stable kernel versions released after this fix was merged upstream. Additionally, implementing rigorous monitoring of device attachment and detachment events can help detect unusual patterns that might trigger such race conditions earlier in the lifecycle of a virtual or physical device configuration change.