The alauda subdriver builds its commands in stack arrays and passes them
to usb_stor_bulk_transfer_buf(). usb_hcd_map_urb_for_dma() rejects a
buffer on the stack, so on a host controller that uses DMA every alauda
command fails. Patch 1 moves the buffers to us->iobuf.

The first command to fail is the one that builds the block map, and
alauda_ensure_map_for_zone() ignores that failure, so the next access
dereferences a NULL map. Patch 2 checks it.

Separately, the zone index used to reach those maps can be num_zones,
one element past the end of both arrays, because max_lba counts physical
blocks while the index is computed from usable ones. Patch 3 bounds it.

Alan Stern <stern@rowland.harvard.edu> wrote an equivalent fix for
patch 1 in 2023, attachment 305027 on the bug below, and offered to let
me post it. Patch 1 here uses us->iobuf directly, as the other
usb-storage subdrivers do, rather than the memcpy that attachment uses.
Alan also diagnosed the NULL dereference in comment 11 of that bug, and
suggested the reordering that is half of patch 3.

None of this makes the card reader work. Alan has said it may be better
to mark the driver BROKEN; that is a separate decision, and these are
bugs in the code either way.

Compile tested only; no relevant hardware available.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217862
Link: https://lore.kernel.org/linux-usb/20260821080951.39905-1-arkamondalofficial@gmail.com/

Arka Mondal (3):
  usb-storage: alauda: do not do DMA from the stack
  usb-storage: alauda: check the return value of alauda_read_map()
  usb-storage: alauda: fix out-of-bounds zone index

 drivers/usb/storage/alauda.c | 95 +++++++++++++++++++++++++-----------
 1 file changed, 67 insertions(+), 28 deletions(-)


base-commit: 2709dd5ae32f0828f386327c76bba9f39f63a1c6
-- 
2.55.0

On Tue, Sep 01, 2026 at 03:58:28PM +0900, Arka Mondal wrote:
> The alauda subdriver builds its commands in stack arrays and passes them
> to usb_stor_bulk_transfer_buf(). usb_hcd_map_urb_for_dma() rejects a
> buffer on the stack, so on a host controller that uses DMA every alauda
> command fails. Patch 1 moves the buffers to us->iobuf.
> 
> The first command to fail is the one that builds the block map, and
> alauda_ensure_map_for_zone() ignores that failure, so the next access
> dereferences a NULL map. Patch 2 checks it.
> 
> Separately, the zone index used to reach those maps can be num_zones,
> one element past the end of both arrays, because max_lba counts physical
> blocks while the index is computed from usable ones. Patch 3 bounds it.
> 
> Alan Stern <stern@rowland.harvard.edu> wrote an equivalent fix for
> patch 1 in 2023, attachment 305027 on the bug below, and offered to let
> me post it. Patch 1 here uses us->iobuf directly, as the other
> usb-storage subdrivers do, rather than the memcpy that attachment uses.
> Alan also diagnosed the NULL dereference in comment 11 of that bug, and
> suggested the reordering that is half of patch 3.
> 
> None of this makes the card reader work. Alan has said it may be better
> to mark the driver BROKEN; that is a separate decision, and these are
> bugs in the code either way.
> 
> Compile tested only; no relevant hardware available.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217862
> Link: https://lore.kernel.org/linux-usb/20260821080951.39905-1-arkamondalofficial@gmail.com/
> 
> Arka Mondal (3):
>   usb-storage: alauda: do not do DMA from the stack
>   usb-storage: alauda: check the return value of alauda_read_map()
>   usb-storage: alauda: fix out-of-bounds zone index
> 
>  drivers/usb/storage/alauda.c | 95 +++++++++++++++++++++++++-----------
>  1 file changed, 67 insertions(+), 28 deletions(-)

For all three patches:

Acked-by: Alan Stern <stern@rowland.harvard.edu>