CVE-2023-53847

usb-storage: alauda: Fix uninit-value in alauda_check_media()

published December 9, 2025

CVSS
—
EPSS
0%
Percentile
14.2
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00239 · 14.2th percentile
Published
2025-12-09T01:30Z
EPSS history
Timeline
  • 09 DEC 01:30Z
    usb-storage: alauda: Fix uninit-value in alauda_check_media()
    cvelistv5