Cloudanix VulnDB

CVE-2026-98758

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux kernel handling of certain USB ports can let local software cause crashes or gain extra system access if the USB hardware is unplugged or the driver is removed at the wrong time.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the Linux kernel UCSI glink driver where notification work items queued by pmic_glink can dereference a connector array or re-register the instance after ucsi_unregister has freed state during module removal.

Why it matters to the business

Linux systems using affected USB Type-C hardware may experience kernel crashes, denial of service, or potential local privilege escalation during device unplug or driver unload, increasing downtime and security risk on servers, laptops, and embedded devices.

How an attack unfolds

An attacker with local access triggers repeated connect/disconnect events or module removal to race the devres cleanup against pending work items, causing the work handler to touch already-freed ucsi structures and potentially leading to arbitrary kernel memory access.

How to fix it

Apply the upstream kernel commit that calls disable_work_sync on both work items before ucsi_unregister and adds a registration guard; rebuild and deploy the fixed kernel to all affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the glink driver source for disable_work_sync calls before unregister, or verify the running kernel version contains the fix and test device removal under load.

Typical attack path

  1. Obtain local code execution on the target Linux system
  2. Trigger USB Type-C events or rmmod on the glink driver to start removal
  3. Race the pmic_glink cleanup window so queued work runs after ucsi_unregister
  4. Use the resulting use-after-free to corrupt kernel memory or redirect execution

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for UCSI glink workqueue or use-after-free oops entries around device removal events; correlate with audit logs showing module unloads or USB disconnects.

  • workqueue: usb: typec: ucsi: glink
  • ucsi_unregister
  • pmic_glink_ucsi_remove

What your security team should do

  • Prioritize kernel updates on all Linux endpoints with Type-C UCSI hardware within the next patch cycle
  • Monitor kernel logs for UCSI-related oops or workqueue warnings during driver unload
  • Restrict unprivileged module loading and USB device access where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: glink: fix use-after-free of ucsi on remove The pmic_glink client is released by the devres cleanup, which runs after pmic_glink_ucsi_remove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsi_unregister() has been called touches freed state: it dereferences the connector array that ucsi_unregister() freed, or registers and unregisters the instance a second time. Disable both work items with disable_work_sync() before unregistering, and unregister only if the instance is still registered. This issue was found by an in-house static analysis tool.

Affected packages

Ecosystem Package Introduced Fixed