CVE-2026-74263 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: check skb_clone in control TX
t7xx_port_ctrl_tx() clones each skb fragment before passing it to the port transmit path. The clone is used immediately to set cloned->len, so an skb_clone() failure results in a NULL pointer dereference.
Check the clone before using it. If previous fragments were already queued, preserve the driver's existing partial-write behavior by returning the number of bytes submitted so far.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the Linux kernel's wwan subsystem, specifically in the t7xx driver implementation that manages communication with certain cellular modems. This issue manifests in the t7xx_port_ctrl_tx() function which handles control message transmission through the WWAN interface. The flaw occurs during the processing of socket buffer (skb) fragments where the driver performs an skb_clone operation to create copies of each fragment before passing them to the transmit path. The technical implementation fails to properly validate the success of this cloning operation, creating a critical null pointer dereference condition when the clone operation returns NULL.
The vulnerability stems from inadequate error handling in the control message transmission pathway where the kernel does not verify whether skb_clone() successfully creates a duplicate of the original socket buffer. When this cloning operation fails, typically due to memory allocation issues or other resource constraints, the code continues execution without checking for the NULL return value from skb_clone(). This results in immediate null pointer dereference when attempting to access properties of the cloned skb structure, leading to kernel panic or system instability. The flaw specifically affects the t7xx driver's control plane operations and represents a classic case of improper error handling that can be exploited to cause denial of service conditions.
The operational impact of this vulnerability extends beyond simple system crashes as it affects the reliability of WWAN communication pathways in devices relying on t7xx modem drivers. When triggered, the null pointer dereference causes immediate kernel termination, requiring system reboot to restore normal operation. This creates significant availability issues for mobile devices, IoT equipment, and embedded systems that depend on cellular connectivity through these specific modem implementations. The vulnerability is particularly concerning in environments where continuous connectivity is required, such as industrial monitoring systems, automotive applications, or emergency communication devices.
Mitigation strategies should focus on implementing proper error checking around the skb_clone() operation within the t7xx_port_ctrl_tx() function. The fix requires adding validation checks to verify that the cloned skb pointer is not NULL before proceeding with operations such as setting cloned->len. When a clone failure occurs, the driver must handle this gracefully by returning the number of bytes successfully submitted so far rather than allowing the system to crash. This approach maintains backward compatibility with existing partial-write behavior while preventing the null pointer dereference condition. The solution aligns with common security best practices for kernel development and addresses the underlying CWE-476 null pointer dereference weakness, ensuring robust error handling in network driver implementations.
This vulnerability demonstrates the critical importance of proper resource management and error validation in kernel space code, particularly in networking drivers where memory allocation failures can have severe consequences. The fix pattern follows established security principles for preventing null pointer dereferences and maintains the driver's existing operational semantics while eliminating the crash condition. The implementation should be tested across various memory pressure scenarios to ensure robustness against similar edge cases that might occur during high-load network operations or resource-constrained environments where memory allocation failures are more likely to manifest.