CVE-2026-46004
Analyzed
Analyzed - Analysis Complete
ALSA caiaq Driver Probe Error Handling Flaw
Publication date: 2026-05-27
Last updated on: 2026-06-16
Assigner: kernel.org
Description
Description
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Handle probe errors properly
The probe procedure of setup_card() in caiaq driver doesn't treat the
error cases gracefully, e.g. the error from snd_card_register() calls
snd_card_free() but continues. This would lead to a UAF for the
further calls like snd_usb_caiaq_control_init(), as Berk suggested in
another patch in the link below.
However, the problem is not only that; in general, this function drops
the all error handlings (as it's a void function) although its caller
can propagate an error to snd_probe(), which eventually calls
snd_card_free() as a proper error path. That said, we should treat
each error case in setup_card(), and just return the error code
promptly, which is then handled later as a fatal error in snd_probe().
This patch achieves it by changing the setup_card() to return an error
code. Also, the superfluous snd_card_free() call is removed, too.
Note that card->private_free can be set still safely at returning an
error. All called functions in card_free() have checks of the
unassigned resources or NULL checks.
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 6.7 (inc) to 6.12.86 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.175 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.209 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.140 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.18.27 (exc) |
| linux | linux_kernel | From 6.19 (inc) to 7.0.4 (exc) |
| linux | linux_kernel | From 2.6.25 (inc) to 5.10.258 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |