stack smashing detected with 'nvme sanitize-log /dev/nvme0'

[Guangwu Zhang]

Hi,

Can not reproduce the bug with our test environment.

5.14.0-344.el9.x86_64
b0:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd
NVMe SSD Controller PM173X

# nvme sanitize-log /dev/nvme0
Sanitize Progress                      (SPROG) :  65535
Sanitize Status                        (SSTAT) :  0
Sanitize Command Dword 10 Information (SCDW10) :  0
Estimated Time For Overwrite                   :  4294967295 (No time
period reported)
Estimated Time For Block Erase                 :  4294967295 (No time
period reported)
Estimated Time For Crypto Erase                :  4294967295 (No time
period reported)
Estimated Time For Overwrite (No-Deallocate)   :  0
Estimated Time For Block Erase (No-Deallocate) :  0
Estimated Time For Crypto Erase (No-Deallocate):  0

Ming Lei <ming.lei at redhat.com> 于2023年7月27日周四 09:30写道：
>
> On Wed, Jul 26, 2023 at 01:52:04PM +0200, Daniel Wagner wrote:
> > FYI, I got a a bug report [1] with a 'stack smashing detected' when running
> > 'nvme sanitize-log /dev/nvme0' on Debian. Originally, it was reported against
> > udisk. udisk recently added libnvme which does now a sanitize-log call, so this
> > problem might exists for a while.
> >
> > We figured out that an older kernel such as 4.19.289 work but newer not (it's a
> > bit hard for the reporter to test all combinations on his setup due to compiler
> > changes etc.).
> >
> > There was a bit of refactoring in v5.2 which could be the cause of the stack
> > smash, because saw this recent fix:
> >
> >  b8f6446b6853 ("nvme-pci: fix DMA direction of unmapping integrity data")
>
> This commit only fixes DMA UNMAP direction for integrity data, but is
> there integrity data involved for 'nvme sanitize-log /dev/nvme0'?
>
>
> Thanks,
> Ming
>


-- 
Guangwu Zhang
Thanks