CVE-2026-74680 in Linuxinfo

Summary

by MITRE • 08/22/2026

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

usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()

If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active.

When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb():

cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------
URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline]
cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ...

To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 08/22/2026

The cxacru driver for USB ATM devices contains a resource management flaw within its control message handling logic. Specifically, when the cxacru_cm function encounters an error during the submission or waiting phase of sending a URB, it aborts and returns the error code without properly terminating the receive URB that was previously submitted. This oversight leaves the rcv_urb in an active state despite the failure of the current operation. The root cause lies in the incomplete cleanup path within the driver's error handling routine, where necessary teardown steps are skipped to expedite return from the function.

This defect manifests primarily during device initialization sequences such as cxacru_atm_start. When a transmission error occurs, the driver may incorrectly proceed with subsequent operations that assume a clean state. For instance, it might invoke cxacru_poll_status which subsequently calls cxacru_cm again. Because the previous rcv_urb was not killed, attempting to submit this still-active URB triggers a kernel warning from usb_submit_urb indicating that an active URB is being resubmitted. This results in diagnostic output showing error codes like -104 and stack traces pointing to the specific lines where the invalid submission occurs, potentially disrupting normal device operation or causing instability during hotplug events.

From a security perspective, this vulnerability aligns with CWE-756: Missing Explanation of Reason for Exclusion if viewed as a logic flaw leading to undefined behavior, but more accurately maps to CWE-401: Memory Leak due to improper resource release and CWE-392: Race Condition in Error Handling. The failure to kill the URB can lead to use-after-free scenarios or kernel panics if the hardware state becomes desynchronized with driver expectations. In terms of MITRE ATT&CK, this represents a weakness that could potentially be leveraged for denial-of-service attacks by triggering repeated initialization failures and kernel warnings, although it is primarily an integrity and stability issue rather than a direct privilege escalation vector.

The remediation involves modifying the error path in cxacru_cm to explicitly call usb_kill_urb on the rcv_urb before returning. This approach is safe because the USB subsystem guarantees that calling usb_kill_urb on an inactive or already completed URB has no adverse side effects, effectively idempotently ensuring the resource is released regardless of its current state. Implementing this fix ensures proper cleanup and prevents the accumulation of active URBs during error conditions. System administrators should apply kernel updates containing this patch to maintain system stability when using cxacru-based USB ATM adapters, particularly in environments where device reconnection or initialization errors are common.

Responsible

Linux

Reservation

08/15/2026

Disclosure

08/22/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!