CVE-2026-23031

What it actually does

Memory leak in the gs_usb USB CAN driver where completed in-URBs are unanchored by the USB framework before the completion callback runs, so they are never released by usb_kill_anchored_urbs on device close.

Why it matters to the business

Long-running systems using the affected USB CAN hardware gradually consume kernel memory, eventually causing performance degradation or denial of service; the issue affects virtualized Linux environments and stable kernel trees with moderate downstream reach.

How an attack unfolds

An attacker with local access repeatedly opens and closes the gs_usb device (or triggers the same sequence via normal driver usage), causing each completed URB to leak; over time the cumulative leaks exhaust memory without any remote vector or authentication bypass.

How to fix it

Upgrade linux-virt and linux-virt-doc packages to version 6.12.27-r0 or later; for custom kernels apply commit ec5ccc2af9e5b045671f3f604b57512feda8bcc5 and rebuild.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking the presence of the re-anchoring call in gs_usb_receive_bulk_callback or by verifying package versions match the fixed releases; monitor memory usage of the gs_usb module over repeated open/close cycles.

Typical attack path

1. Obtain local access or execute code on a system with the vulnerable gs_usb driver loaded
2. Open the CAN USB device to allocate and submit anchored in-URBs
3. Allow or force completion of the URBs so the USB core unanchors them
4. Close the device; the leaked URBs remain allocated
5. Repeat the cycle to accumulate memory pressure until the system is impacted

How to detect it

Examine kernel memory statistics and slabinfo for increasing allocations attributed to URB or gs_usb structures; correlate with audit or system logs showing repeated gs_can_open and gs_can_close activity on USB CAN devices; no public exploit artifacts exist.

What your security team should do

• Apply the listed kernel package upgrades immediately on all affected systems
• Prioritize systems that expose the gs_usb driver to untrusted local users or containers
• Add the fixed commit to any internal kernel build pipelines and re-test USB CAN functionality
• Review EPSS trend and re-assess in 30 days if new exploit code appears