CVE-2026-46048

ALSA: caiaq: fix usb_dev refcount leak on probe failure

MEDIUM
5.5
CVSS Score
Published: May 27, 2026 at 12:57 PM UTC
Updated: June 17, 2026 at 10:52 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.1%

Description

In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix usb_dev refcount leak on probe failure create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor. However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new().

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.12.84 ≤ v < 6.12.866.18.25 ≤ v < 6.18.276.6.136 ≤ v < 6.6.1407.0.2 ≤ v < 7.0.41d9be95aee6c6246a21752e60c9519902649f482493b3a682ededc804555755f5d2193201339612d59b622a043cffc58b7638cd85ae6c30a0904f8e66.12.846.18.256.6.1366473ed16df1fe88051140611b3eb9a49be7f429e7.0.27.1 rc180bb50e2d459213cccff3111d5ef98ed4238c0d5ac7345f68cda6989016d85d63f7b244c064aa8f6dbcf7588e8dea017ddb3f18ec2766f7d2e5f2a0ef6634af5de728a46792f674a66d7843570cb68f7
Vendor states this is fixed in 21ca595aafa40d3ac70eab1f4cb62cc00ca21657 (fixed)
Vendor states this is fixed in 50c6a1f05973f56d23280c9d7645a7a5734e0907 (fixed)
Vendor states this is fixed in 6153878c5255bb69b7d0868105ca078ef13cbcf8 (fixed)
Vendor states this is fixed in 6fa8dff64fb6c401ced40a05797b327659317498 (fixed)
Vendor states this is fixed in 7a5f1cd22d47f8ca4b760b6334378ae42c1bd24b (fixed)
Vendor states this is fixed in a8d907acc3e5a078c2e5637ff60c30c6d2ddc23a (fixed)
Vendor states this is fixed in c874db8a1d2f9f08161470d00cfe8db2f5cca2cc (fixed)
Vendor states this is fixed in da3b8fd6a202d94fef11a443abc9171c52426a1c (fixed)
Affected range stops below 6.12.86, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.18.27, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.6.140, so it looks safe — our inference, not a vendor statement
Affected range stops below 7.0.4, so it looks safe — our inference, not a vendor statement

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
NVD-CWE-Other

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card