CVE-2026-64463

What it actually does

This is a Linux kernel driver lifetime-management flaw in the Realtek RT1711H USB Type-C Port Controller Interface driver. During rt1711h_probe(), the driver registers a TCPCI port before later initialization steps, such as interrupt request and alert interrupt enablement, are complete. If those later steps fail, the probe path can return without unregistering the previously registered TCPCI port. That leaves kernel-managed Type-C/TCPCI state associated with a failed or partially initialized device, which can lead to stale references, use-after-free conditions, kernel memory corruption, or denial of service when the kernel later interacts with the orphaned port object. The CVSS vector indicates local exploitation with low privileges and potential high confidentiality, integrity, and availability impact if the bug can be reliably triggered and exploited.

Why it matters to the business

Successful exploitation could allow a local attacker to crash affected Linux systems or potentially escalate privileges, compromising workloads that rely on those hosts. The operational risk is highest for laptops, embedded devices, appliances, or servers that include the RT1711H USB Type-C controller or load the affected driver. This issue is not currently listed in CISA KEV, is not reported as ransomware-used, has low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, kernel privilege-escalation issues remain important because they can turn limited local access into full host compromise.

How an attack unfolds

An attacker first needs local code execution on a system running an affected Linux kernel with the tcpci_rt1711h driver available and relevant hardware or probe conditions present. The attacker attempts to influence driver probing or device initialization so that tcpci_register_port() succeeds but a later probe step, such as IRQ registration or alert interrupt enablement, fails. Because the failed probe path does not unregister the TCPCI port, the kernel may retain a stale or partially initialized port object. The attacker then attempts to trigger later Type-C, TCPCI, sysfs, power-management, driver-bind, or device-removal activity that causes the kernel to access the invalid state. In the simplest case this results in a kernel oops or panic; with reliable heap shaping and control over timing, it may be possible to turn the stale reference into local privilege escalation or kernel memory disclosure/modification.

How to fix it

Upgrade to a Linux kernel or vendor-maintained kernel package that includes the fix for this driver. The corrected implementation registers a devres cleanup action immediately after tcpci_register_port() succeeds so tcpci_unregister_port() is called on later probe failures and driver detach, and avoids duplicate unregister during removal. No exact fixed package versions were provided, so use the fixed kernel version supplied by the relevant Linux distribution, device vendor, or appliance vendor. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the tcpci_rt1711h driver if RT1711H USB Type-C functionality is not required, restricting local shell access, limiting the ability to load/unload kernel modules, disabling unneeded device hotplug paths where feasible, and monitoring for kernel instability around USB Type-C or TCPCI events.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed release and that the source or vendor patch includes devres-managed cleanup for tcpci_unregister_port() after successful tcpci_register_port() in rt1711h_probe(). On source-based systems, review drivers/usb/typec/tcpm/tcpci_rt1711h.c for the corrected cleanup behavior. On deployed systems, confirm the active kernel with uname -a and package-manager metadata, and ensure the host has rebooted into the fixed kernel rather than merely installing it. If the driver is mitigated instead of patched, verify that tcpci_rt1711h is not loaded with lsmod, modinfo, and kernel module blacklist configuration. Check dmesg or journalctl -k after reboot and after Type-C device activity for absence of RT1711H/TCPCI probe failures, KASAN reports, kernel oops messages, or panic events.

Typical attack path

1. Obtain local low-privileged execution on a Linux system where the affected RT1711H TCPCI driver is present or loadable.
2. Identify whether the tcpci_rt1711h driver is loaded, built into the kernel, or can be triggered through device enumeration or driver binding.
3. Cause or wait for an RT1711H probe sequence where TCPCI port registration succeeds but a later initialization step fails.
4. Use repeated bind/unbind, device reset, power-management, Type-C connection-state changes, or related local triggers to exercise the stale TCPCI port state.
5. Observe whether the system produces kernel oops, KASAN use-after-free reports, warnings, or panics.
6. If pursuing privilege escalation, combine the stale kernel object access with heap grooming and controlled reallocation to influence kernel memory behavior.

How to detect it

Review kernel logs and crash artifacts for signs that the RT1711H TCPCI driver encountered probe failures followed by stale object access, memory-safety errors, or system crashes. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, systemd-coredump metadata, kdump/vmcore files, pstore/ramoops, and EDR telemetry that records kernel oops or panic events. Look for KASAN or slab allocator reports referencing tcpci_rt1711h, rt1711h_probe, tcpci_register_port, tcpci_unregister_port, tcpm, or Type-C port operations. Also investigate repeated module load/unload, driver bind/unbind, device reset, or Type-C hotplug activity immediately before kernel warnings or crashes. Because no public exploit indicators were provided, detection should focus on behavioral evidence: abnormal local activity around driver probing, suspicious access to sysfs driver bind/unbind controls, unexplained kernel crashes, and memory-corruption reports involving the affected driver.

• tcpci_rt1711h
• rt1711h_probe
• tcpci_register_port
• tcpci_unregister_port
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG at drivers/usb/typec
• drivers/usb/typec/tcpm/tcpci_rt1711h.c
• Unable to handle kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• /sys/bus/i2c/drivers/rt1711h/bind
• /sys/bus/i2c/drivers/rt1711h/unbind
• /sys/module/tcpci_rt1711h
• modprobe tcpci_rt1711h
• rmmod tcpci_rt1711h

What your security team should do

• Prioritize patching Linux systems that expose local user access and include RT1711H USB Type-C hardware or load the tcpci_rt1711h driver.
• Track distribution and vendor advisories for the exact fixed kernel package because no fixed versions were provided in the input.
• Reboot systems after kernel updates and verify they are running the remediated kernel, not just that the package is installed.
• If patching is delayed and the hardware is not required, blacklist or disable the tcpci_rt1711h module as a compensating control.
• Restrict local interactive access, kernel module loading, device driver binding/unbinding, and hardware-management privileges to trusted administrators.
• Enable and review kernel telemetry, including dmesg, journalctl -k, crash dumps, and EDR kernel-panic signals, for Type-C/TCPCI-related failures.
• Treat unexplained kernel oops or panic events involving tcpci_rt1711h, tcpci, tcpm, or USB Type-C as potential exploitation attempts until ruled out.
• Because this is not KEV-listed, not known ransomware-used, and has very low EPSS, schedule broad fleet remediation through normal kernel patch cycles while fast-tracking systems with higher local-user or physical-access risk.