CVE-2026-98760 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect()
tps6598x_connect() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity.
typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs.
Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero.
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's Type-C Port Controller Driver for Texas Instruments TPS6598x chips represents a critical memory safety issue rooted in improper initialization of stack-allocated data structures. Specifically, within the tps6598x_connect function, a typec_partner_desc structure is allocated on the call stack but only partially initialized before being passed to the core Type-C subsystem for registration. The developer correctly initializes fields related to USB Power Delivery specifications, accessory identification, and partner identity information; however, critical callback pointers such as attach and detach remain uninitialized. In C programming, local variables that are not explicitly zeroed out retain whatever data previously existed in those memory locations on the stack. This oversight creates a scenario where undefined or garbage values persist within the structure fields intended to hold function pointers for handling connection events.
The operational impact of this flaw is severe due to how the Type-C core subsystem processes partner descriptors during device registration. When typec_register_partner is invoked, it copies specific members from the provided descriptor into the internal partner object representation. Because the attach and detach function pointer fields were left uninitialized, these garbage values are copied directly into the kernel's memory space representing the USB partner. Subsequently, when a USB device is linked to the port or undergoes state transitions that trigger partner link operations via typec_partner_link_device(), the kernel attempts to invoke these stored pointers as functions. Since the addresses point to arbitrary stack locations rather than valid code segments, this results in an invalid memory access event. This typically manifests as a kernel panic, system crash, or denial of service condition, effectively destabilizing the host system whenever such a device is connected and linked.
Beyond immediate stability risks, the vulnerability also presents information disclosure concerns through side channels involving sysfs interfaces. The typec_partner_desc structure contains additional fields like pd_revision and usb_capability that are similarly left uninitialized in the original code path. When these structures are exposed to user space via sysfs attributes for diagnostic or configuration purposes, they leak raw stack memory contents. This constitutes an out-of-bounds read vulnerability where sensitive kernel data from previous function calls can be exfiltrated by a local attacker with access to the device's file system interface. While this may not directly lead to code execution, it violates principles of information isolation and could potentially aid in further exploitation attempts by revealing memory layout or other process states.
From a classification perspective, this issue aligns closely with CWE-457, which describes the use of an uninitialized variable, specifically within the context of C/C++ systems programming where stack variables are not explicitly zeroed before use. The potential for executing arbitrary code through corrupted function pointers also relates to CWE-94, improper control of generation of code, although in this specific instance, the primary vector is denial of service via kernel panic rather than successful privilege escalation due to modern mitigations like non-executable stack pages often present in Linux distributions. In terms of attack patterns, this vulnerability facilitates local exploitation scenarios that could be categorized under ATT&CK technique T1059, Command and Scripting Interpreter, if an attacker leverages the resulting instability for further system compromise, or more accurately reflects memory corruption vulnerabilities leading to service disruption akin to resource exhaustion attacks in availability-focused threat models.
To mitigate this vulnerability, the primary remediation involves ensuring that all members of stack-allocated structures are explicitly initialized before use. The recommended fix is to zero-initialize the typec_partner_desc structure at the point of declaration or immediately prior to passing it to registration functions. This guarantees that optional callback pointers default to NULL and numeric fields like pd_revision start with a defined value rather than garbage data. Developers should adopt coding standards that mandate explicit initialization of all struct members, particularly those containing function pointers, to prevent undefined behavior. Static analysis tools configured to detect uninitialized variable usage can also help identify similar patterns in other parts of the kernel codebase before they reach production environments.