CVE-2023-53847
usb-storage: alauda: Fix uninit-value in alauda_check_media()
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
Descriptions
In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Fix uninit-value in alauda_check_media() Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage: BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460 The problem is that alauda_check_media() doesn't verify that its USB
transfer succeeded before trying to use the received data. What
should happen if the transfer fails isn't entirely clear, but a
reasonably conservative approach is to pretend that no media is
present. A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status(). In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message. Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this. We'll use it instead.
In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Fix uninit-value in alauda_check_media() Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage: BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460 The problem is that alauda_check_media() doesn't verify that its USB transfer succeeded before trying to use the received data. What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present. A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status(). In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message. Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this. We'll use it instead.
CVSS Scores
SSVC
- Decision:-
Timeline
- 2025-12-09 CVE Reserved
- 2025-12-09 CVE Published
- 2025-12-09 CVE Updated
- 2025-12-15 EPSS Updated
- ---------- Exploited in Wild
- ---------- KEV Due Date
- ---------- First Exploit
CWE
CAPEC
References (9)
| URL | Tag | Source |
|---|---|---|
| https://git.kernel.org/stable/c/e80b0fade09ef1ee67b0898d480d4c588f124d5f | Vuln. Introduced |
| URL | Date | SRC |
|---|
| URL | Date | SRC |
|---|
Affected Vendors, Products, and Versions
| Vendor | Product | Version | Other | Status | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Vendor | Product | Version | Other | Status | <-- --> | Vendor | Product | Version | Other | Status |
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 4.14.323 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 4.14.323" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 4.19.292 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 4.19.292" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 5.4.254 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 5.4.254" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 5.10.191 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 5.10.191" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 5.15.127 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 5.15.127" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 6.1.46 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 6.1.46" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 6.4.11 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 6.4.11" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 2.6.16 < 6.5 Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.16 < 6.5" | en |
Affected
| ||||||
