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

[Bart Van Assche]

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.