CVE-2026-53305

What it actually does

This is a Linux kernel denial-of-service flaw in the USB Type-C ps883x retimer driver. During device removal or driver unbind, ps883x_retimer_remove() calls i2c_get_clientdata(), but the probe path did not initialize that driver data with i2c_set_clientdata(). As a result, removal can dereference a NULL pointer, producing a kernel Oops at an address such as 0x20. Depending on kernel panic-on-oops settings and workload, this may crash the host, destabilize the kernel, or require a reboot. The issue is local in nature and is most relevant on systems that include or load the affected ps883x Type-C retimer driver.

Why it matters to the business

The practical risk is unexpected system instability or outage when an affected USB Type-C retimer device is unbound, removed, reprobed, or otherwise detached from its driver. Because exploitation generally requires local administrative capability to unbind kernel devices or trigger equivalent device-removal paths, internet-scale exploitation risk is low. The CVE is not listed in CISA KEV, is not reported as used in ransomware campaigns, has no known mature exploit, and has a low EPSS score of 0.00121; however, production systems using affected hardware should still be patched through normal kernel maintenance because a kernel crash can interrupt services and require manual recovery.

How an attack unfolds

An attacker or local administrator with sufficient privileges identifies a Linux system using the affected ps883x USB Type-C retimer driver. They trigger the driver removal path, for example by writing the relevant device identifier to a sysfs driver unbind interface or by causing an equivalent device detach/unbind event. When the kernel executes the ps883x removal routine, it attempts to retrieve per-device driver data that was never initialized during probe. The NULL driver-data pointer is then dereferenced, causing a kernel Oops in ps883x_retimer_remove(). If the system is configured to panic on oops, or if the fault leaves critical device state inconsistent, the system may crash or require reboot. There is no public indication from the provided data that this flaw enables privilege escalation, data theft, or remote code execution.

How to fix it

Upgrade to a Linux kernel build from the distribution, vendor, or upstream branch that includes the ps883x retimer fix adding i2c_set_clientdata() during probe. No exact fixed package versions were provided, so use the kernel security advisory or stable-kernel changelog for the deployed distribution or device vendor. If immediate patching is not possible, reduce exposure by avoiding manual unbind/rebind operations for ps883x retimer devices on production systems, restricting root and device-management access, disabling unnecessary debug or maintenance workflows that manipulate sysfs driver binding, and considering whether the affected driver can be disabled or not loaded on systems that do not require it. Treat mitigations as temporary; the proper fix is a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or image includes the upstream/vendor patch for the ps883x retimer remove-path NULL pointer dereference. Review kernel package changelogs, distribution advisories, or source to confirm that the driver probe path sets client data before removal. On non-production test hardware with the affected retimer, a controlled bind/unbind or device-removal test should no longer produce an Oops in ps883x_retimer_remove(). Also verify that kernel logs remain free of NULL pointer dereference, Data abort, or Oops messages associated with ps883x_retimer_remove after retimer removal or driver reload events.

Typical attack path

1. Gain local access with privileges sufficient to manage kernel devices, drivers, or sysfs unbind interfaces, typically root or equivalent administrative capability.
2. Confirm that the affected Linux kernel driver for the ps883x USB Type-C retimer is present and bound to a compatible device.
3. Trigger the affected device-removal path, such as through a sysfs driver unbind operation or an equivalent hot-remove/unbind event.
4. The kernel calls ps883x_retimer_remove() during removal.
5. The remove routine retrieves unset driver data and dereferences a NULL pointer.
6. The system records a kernel Oops and may become unstable, panic, or require reboot depending on configuration.

How to detect it

Look for evidence that the vulnerable removal path was triggered before patching. Primary sources are kernel logs and persistent system journals, including dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, and crash dump collection systems such as kdump. Search for kernel Oops records containing ps883x_retimer_remove, i2c_device_remove, NULL pointer dereference near address 0000000000000020, or sysfs unbind activity involving platform or I2C devices shortly before the crash. Correlate these events with auditd, shell history, sudo logs, process accounting, or EDR telemetry showing writes to /sys/bus/*/devices/*/driver/unbind. Because the expected impact is denial of service rather than persistence or code execution, detection should focus on crash artifacts, reboot timelines, kernel panic records, and privileged commands that manipulated driver binding. No named threat actors or active exploitation campaigns were provided for this issue.

• ps883x_retimer_remove
• i2c_device_remove
• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
• Internal error: Oops: 0000000096000004
• FSC = 0x04: level 0 translation fault
• Data abort info:
• /sys/bus/platform/devices/
• /driver/unbind
• echo * > /sys/bus/*/devices/*/driver/unbind
• bc0000.geniqup
• usb: typec: ps883x
• i2c_get_clientdata
• i2c_set_clientdata

What your security team should do

• Inventory Linux systems and embedded devices using USB Type-C retimer hardware or loading the ps883x retimer driver.
• Prioritize patching on production systems where kernel crashes would cause service interruption, even though exploitation likelihood is currently low.
• Apply vendor-supported kernel updates that include the ps883x fix; avoid relying on manual source patches unless that is part of the established kernel maintenance process.
• Restrict administrative shell access and permissions to write to sysfs driver bind/unbind interfaces.
• Monitor kernel logs for Oops, NULL pointer dereference, and ps883x_retimer_remove events to identify accidental triggering or potential abuse.
• If affected hardware is present but unused, evaluate disabling the vulnerable driver until a patched kernel can be deployed.
• Track vendor advisories because this kernel fix may arrive through distribution-specific package names and versioning rather than a single universal fixed version.