Fixed
Created: Dec 10, 2025
Updated: Dec 11, 2025
Resolved Date: Dec 10, 2025
Found In Version: 10.22.33.1
Fix Version: 10.22.33.13
Severity: Standard
Applicable for: Wind River Linux LTS 22
Component/s: Kernel
In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]usb-storage: alauda: Fix uninit-value in alauda_check_media()[EOL][EOL]Syzbot got KMSAN to complain about access to an uninitialized value in[EOL]the alauda subdriver of usb-storage:[EOL][EOL]BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0[EOL]drivers/usb/storage/alauda.c:1137[EOL]CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0[EOL]Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS[EOL]Google 01/01/2011[EOL]Call Trace:[EOL] __dump_stack lib/dump_stack.c:77 [inline][EOL] dump_stack+0x191/0x1f0 lib/dump_stack.c:113[EOL] kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108[EOL] __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250[EOL] alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460[EOL][EOL]The problem is that alauda_check_media() doesn't verify that its USB[EOL]transfer succeeded before trying to use the received data. What[EOL]should happen if the transfer fails isn't entirely clear, but a[EOL]reasonably conservative approach is to pretend that no media is[EOL]present.[EOL][EOL]A similar problem exists in a usb_stor_dbg() call in[EOL]alauda_get_media_status(). In this case, when an error occurs the[EOL]call is redundant, because usb_stor_ctrl_transfer() already will print[EOL]a debugging message.[EOL][EOL]Finally, unrelated to the uninitialized memory access, is the fact[EOL]that alauda_check_media() performs DMA to a buffer on the stack.[EOL]Fortunately usb-storage provides a general purpose DMA-able buffer for[EOL]uses like this. We'll use it instead.