Re: [PATCH v5] scsi: fill in DMA padding bytes in scsi_alloc_sgtables

[Petr Vaganov]

Yes, the warning is triggered by kmsan_handle_dma_sg(). However, the 
KMSAN report does not appear to be a false positive. There is an actual 
initialization issue: scsi_alloc_sgtables() extends the last scatterlist 
entry by pad_len, but these additional bytes are not initialized before 
the buffer is mapped for DMA. As a result, uninitialized kernel memory 
may become visible to the device during a DMA_TO_DEVICE transfer.

This is exactly the kind of issue KMSAN is intended to detect. The KMSAN 
documentation explicitly mentions passing uninitialized memory to 
hardware as a security issue.

Initializing the padding unconditionally does add some overhead. 
However, sg_zero_buffer() is only called for requests that actually 
require DMA padding. In my opinion, this overhead is preferable to 
leaving uninitialized kernel memory exposed to the device.

Thanks,
Petr

On 7/23/26 01:27, Bart Van Assche wrote:
> On 6/28/26 11:52 AM, Petr Vaganov wrote:
> > During fuzz testing, the following issue was discovered:
> >
> > BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310
> >   __dma_map_sg_attrs+0x217/0x310
> >   dma_map_sg_attrs+0x4a/0x70
> >   ata_qc_issue+0x9f8/0x1420
> >   __ata_scsi_queuecmd+0x1657/0x1740
> >   ata_scsi_queuecmd+0x79a/0x920
> >   scsi_queue_rq+0x4472/0x4f40
> >   blk_mq_dispatch_rq_list+0x1cca/0x3ee0
> >   __blk_mq_sched_dispatch_requests+0x458/0x630
> >   blk_mq_sched_dispatch_requests+0x15b/0x340
> >   __blk_mq_run_hw_queue+0xe5/0x250
> >   __blk_mq_delay_run_hw_queue+0x138/0x780
> >   blk_mq_run_hw_queue+0x4bb/0x7e0
> >   blk_mq_sched_insert_request+0x2a7/0x4c0
> >   blk_execute_rq+0x497/0x8a0
> >   sg_io+0xbe0/0xe20
> >   scsi_ioctl+0x2b36/0x3c60
> >   sr_block_ioctl+0x319/0x440
> >   blkdev_ioctl+0x80f/0xd70
> >   __se_sys_ioctl+0x219/0x420
> >   __x64_sys_ioctl+0x93/0xe0
> >   x64_sys_call+0x1d6c/0x3ad0
> >   do_syscall_64+0x4c/0xa0
> >   entry_SYSCALL_64_after_hwframe+0x6e/0xd8
>
> dma_map_sg_attrs() shouldn't touch the data buffer. Is the above warning
> triggered because of the kmsan_handle_dma_sg() call in
> __dma_map_sg_attrs()?
>
>
> >           last_sg->length += pad_len;
> > +        sg_zero_buffer(last_sg, 1, pad_len, data_len);
> >           cmd->extra_len += pad_len;
>
> Shouldn't sg_zero_buffer() only be called if CONFIG_UBSAN is enabled to
> prevent that this call negatively affects I/O performance?
>
> Thanks,
>
> Bart.