CVE-2026-98763

What it actually does

Dangling pointer left in one of the dev->ep_in or dev->ep_out arrays for a non-zero control endpoint after usb_disable_endpoint clears only the direction indicated by the endpoint address bit, allowing subsequent access to already-freed usb_host_endpoint memory.

Why it matters to the business

Potential kernel instability, denial of service, or local privilege escalation on Linux systems that process USB devices; low immediate operational urgency given five-day publication age, flat low EPSS, and absence from KEV.

How an attack unfolds

An attacker supplies a USB device exposing a non-zero control endpoint; the kernel populates both direction arrays with the same endpoint struct, then on disable only one array slot is cleared, leaving the other pointing at freed memory that the attacker later triggers for use-after-free exploitation.

How to fix it

Apply the upstream fix that clears both dev->ep_out[epnum] and dev->ep_in[epnum] for non-ep0 control endpoints inside usb_disable_endpoint when reset_hardware is true; rebuild and boot the updated kernel on all affected Linux distributions.

How to confirm the fix worked

Inspect usb_disable_endpoint source to confirm both direction arrays are cleared for control endpoints; boot a test kernel with dummy_hcd/raw-gadget, enumerate a non-zero control endpoint device, disable the interface, and verify both array slots are NULL.

Typical attack path

1. Present a USB device or gadget with non-zero control endpoint (bEndpointAddress 0x01, USB_ENDPOINT_XFER_CONTROL)
2. Allow enumeration and interface activation so both ep_in and ep_out slots are populated
3. Trigger interface or endpoint disable with reset_hardware set
4. Reuse or dereference the uncleared array entry to access freed memory
5. Escalate via classic UAF primitives (object replacement, ROP, etc.)

How to detect it

Review dmesg and kernel logs for USB endpoint disable paths, slab UAF warnings, or crashes involving usb_enable_endpoint/usb_disable_endpoint around the time of unexpected device enumeration; correlate with audit logs of USB device attach events.

What your security team should do

• Schedule kernel updates within standard patch windows given low EPSS and no KEV listing
• Restrict untrusted USB device attachment via USBGuard or physical port controls until kernels are updated
• Include the USB core fix in the next automated kernel rollout and golden image rebuilds