CVE-2026-43432 Linux CVE debrief

Who should care

Linux fleet owners, kernel maintainers, and platform teams running systems with USB/xHCI support should care most. The issue is local and requires the right device/state conditions, but it can still cause availability degradation over time on affected kernels.

Technical summary

The supplied NVD record classifies the issue as CWE-401 and gives it CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (5.5 MEDIUM). The vulnerability is a memory leak in usb:xhci error handling: xhci_disable_slot() used kfree() on a command object that may also own a completion structure allocated by xhci_alloc_command(). Because xhci_free_command() frees both pieces, replacing kfree() with that helper resolves the leak. NVD lists affected Linux kernel version ranges across multiple release lines, and the record includes kernel patch references for the fix.

Defensive priority

Medium — patch as part of routine kernel maintenance, and prioritize systems that run affected Linux kernel lines with active USB/xHCI use or broad local user access.

Recommended defensive actions

• Apply the kernel fix or a vendor backport that replaces kfree() with xhci_free_command() in xhci_disable_slot().
• Check deployed kernels against the affected version ranges listed by NVD and prioritize any hosts in the 4.19, 5.4, 5.10, 5.15, 5.16, 6.2, 6.7, 6.13, 6.19, or 7.0-rc lines.
• Plan a reboot into the patched kernel after update, since the issue is in kernel memory management.
• Use the official kernel patch references in the record to confirm your distro or vendor has incorporated the fix.
• Treat this as an availability hardening item rather than a confidentiality or integrity exposure, based on the supplied CVSS vector.

Evidence notes

The description and NVD metadata indicate a Linux kernel USB xHCI memory leak resolved by using xhci_free_command() instead of kfree() in xhci_disable_slot(). NVD marks the vulnerability as analyzed, assigns CWE-401, and provides CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The supplied dates show the CVE was published on 2026-05-08 and modified on 2026-05-20. The record also states the bug was found by an experimental static analysis tool on v6.13-rc1, verified to persist in mainline, and not reliably triggered in runtime testing because the error paths require specific hardware/state conditions.

Official resources