---
id: "CVE-2026-98933"
kind: "vulnerability"
aliases: ["CVE-2026-98933"]
title: "Linux kernel: USB 3 root hub resume timing causes crashes on AMD"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["amd", "kernel", "linux", "runtime", "usb"]
not_affected_if: []
published_at: "2026-10-23T13:17:14+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98933", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98933", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: USB 3 root hub resume timing causes crashes on AMD

The Linux kernel holds a USB 3 hub runtime power-management reference for 200ms during resume, which triggers an AMD platform issue that can crash systems using frequent USB polling such as Android adb. The fix shortens the hold to 120ms for USB 3 root hubs while keeping 200ms for external hubs.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Install a Linux kernel that includes the upstream change "usb: hub: use shorter 120ms post resume hold for SS root hubs" (exact fixed version not stated in the sources)
- Workaround per sources: disable USB runtime PM, which also prevents the issue

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98933
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98933

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

usb: hub: use shorter 120ms post resume hold for SS root hubs

Holding a USB3 hub PM runtime reference for 200ms at hub resume triggers
an AMD platform issue.  Users running Android adb report crashes after
adb has been polling and waking up the USB subsystem once a second for
some time.  Vendors are working on a solution.  Disabling USB runtime PM
is one way to prevent this issue, but it is also proven that reducing the
hold time to 120ms in resume also mitigates it.  See Link for more
details.

Reducing the hold time to 120ms for the USB3 roothub is in itself a valid
change and optimization, as the current 200ms is excessive: a root hub
has no upstream suspended hub whose wake propagation needs to be
accounted for, but still need some time for USB3 link training to
complete.

Keep the 200ms hold for external hubs that commit 8f5b7e2bec1c
("usb: hub: fix detection of high tier USB3 devices behind suspended
hubs") is intended for.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_